バックアップチェックのベストプラクティス

管理者が自動バックアップのためにシステムを作成し、それを忘れる場合、これは一般的な状況です。システムが管理者の通知に失敗した後にのみ、そのバックアップシステムは以前に破損したか、何らかの障害のためにバックアップを復元できず、現在のバックアップ元がありません。

ファイアドリルを実行します... 2、3か月ごとにXYZシステムがダウンしていると言うのは良い考えです...その後、実際に新しいVMなどにオンラインに戻すという動きを経験します。間違い。

soapboxモード：オン

定期的にテストされていないバックアップは無価値であるということは簡単だと思います。

私の以前の仕事には、すべてのシステム（生産、テスト、開発の監視など）を6か月ごとにテスト復元するというポリシーがありました。

また、これは最も若い管理者の仕事であったため、ドキュメントは最新のものでした。ジュニアは、特定のシステムでどれだけの仕事をしているかによって定義され、いつか（実際には非常に頻繁に）それを行ったのは「グループマネージャー」でした

この専用の特別なハードウェア（Intel 1つとIBM / AIXボックス1つ）があり、復元されたホスト上で実際の何かを実行する必要がなかったため、ディスクスペース以外のすべてに対して低スペックでした。

最初の数ラウンドは非常に多くの作業を行いましたが、バックアップの重要な部分である復元プロセスを合理化することにつながりました。

バックアップジョブが「壊れる」ことを管理者が気づかず、作業中のバックアップが適切に機能しないほどではないという事実に言及しているように見えるため、バックアップの周りに何らかの監視スクリプトを構築することをお勧めします。

自家製のバックアップソリューションを構築する場合、次のようなことを行います。

• データをバックアップするスクリプトを作成します。
• テスト復元を実行して、スクリプトが正しく機能することを確認します。
• スクリプトで、または他の手段を使用して、バックアップのステータス（成功、失敗、実行、実行されなかった）を追跡する方法を実装します。
• 追跡ステータスを監視する（電子メール、データベースなど）

それがすべて完了したら、大丈夫です。追加の作業として、定期的なテスト復元を実行します。あなたが原因に寄付する追加のハードウェアがある場合。

私が働いている場所にはウォームサイトがあり、月に一度システムまたはデータベースをランダムに選択して、ウォームサイトにアクセスし、ベアメタルでテスト復元演習を実行して、データを回復できるようにします。

正直なところ、データが非常に重要な場合は、バックアップを管理するためにいくつかのソフトウェアに投資することをお勧めします。安価でシンプルなものからエンタープライズクラスまで、このための製品は何百もあります。

企業のバックアップのためにcrontabで実行されている手書きのスクリプトのセットに依存している場合、遅かれ早かれ、やけどする可能性があります。

「本番」システムの60％サイズの「参照」バージョンがあり、それらを変更の最終テストに使用し、これらのシステムに「本番」バックアップを復元します-バックアップをテストし、両方の環境が互いに連動していることを確認します。

1つのアプローチは、定期的に実行する「回復」ジョブのスクリプトを作成することです。たとえば、最新のバックアップから特定のテキストファイルを取得し、その内容をメールで送信します。可能であれば、データを作成またはバックアップしたボックスとは異なるボックスを使用して、少なくとも必要な場合は、必要に応じて機能するようにする必要があります。利点は、暗号化/復号化、圧縮、およびストレージのメカニズムがすべて機能していることを確認できることです。

これは、電子メールサーバーやデータベースサーバーなどの特殊なバックアップではもう少し複雑になりますが、小規模なDBまたはブリックレベルのメールボックスバックアップから何らかの小規模な復旧を実行し、内容を確認することは確かに可能です。

また、このアプローチは、緊急時にデータを回復できるようにするために定期的なフルリストアを置き換えるものではありません。これにより、日々のバックアップジョブの整合性についてもう少し自信を持つことができます。

テスト復元を実行するとき、「これは見栄えがよく、ファイルが復元され、ファイルが欠落していない、サイズが一致しているように見える」、または「これは見栄えが良い、アプリケーションを開始しました」という点ではあまり快適ではありません。 ..はクラッシュせず、適切なデータを表示します」。

私は最初から、サーバー/クラスタを復元したい、その後、実際のためにそれを使用して制作。1分でも1時間でもなく、永久に。復元が成功したと主張する場合、本番を開始しない理由はまったくありません。これは「汚い」システムではなく、忘れてはならないものです。これは、実際の災害後に直面するシステムです。したがって、「見栄えの良い」ステージを通過した場合は、それと一緒にライブします。翌夜にバックアップしてください。元のものを忘れてください。おそらくされます。このアプローチを使用して、いくつかの不具合を発見し、あなたがされ強制するためにそれらのすべてを修正します。同じシステムの次の復元では、100％成功する可能性が十分にあります。

これには、バックアップソフトウェアとサーバーが含まれます。はい、これらも復元する必要があります。

復元専用のハードウェアを購入する予算はありませんか？

• 絶対に予算が必要であることを強調してください。あらゆる機会に、意思決定者に、有効な復元テスト全体がまだ行われていないことを思い出させてください。（そして、はい、あなたのお尻をカバーする証拠を収集します。タフな世界。）
• ほとんどの組織では、あるシステムを別のハードウェアに移行するビジネス上のニーズがあることがありますので、この機会を利用してください。移行には常に「バックアップから復元する」方法を選択します。元のハードウェアを紛失したように見せかけます。はい、それはより多くのダウンタイムを意味します、それについて申し訳ありません。少なくとも、バックアップが有用であると確信できます。
• 移行なし？ハードウェアを2週間借りて、2つの復元テストを実行できます（借りたハードウェアに復元し、1週間以上待機し、借りたものから元の状態に復元し、そのまま使用します）。通常、何らかの新しいシステム用に購入した新しいハードウェアがあり、適切に整理すれば、簡単に借りることができます。2週間徹底的にテストすることを提案します。新しいハードウェアが古いハードウェアと100％同一でない場合、テストはさらに改善されます。実際の災害時に同一のハードウェアを入手したかどうかをどのように確認しますか？
• 現在、新しいシステムが実装されていますか？今すぐ復元をテストできますか？追加のハードウェアを使用せずに、新しいシステムを上書きするだけで、すぐに再実装する方法を知っているためです。これは、重要なデータがまだない場合に機能します。繰り返しますが、新しく再インストールされたバージョンではなく、復元されたバージョンで本番環境に移動します。

1. 消防訓練。
2. 6か月ごとにすべてのバックアップをテストするポリシーは非常に良い考えです
3. テストに関しては、バックアップする各アプリケーションまたはシステムを調べる必要があります。理想的には、「成功」または「回復可能な」バックアップを構成するものは、バックアップのサービス記述またはSOP（運用ドキュメント）に、保持時間、bladiblaなどの他の詳細とともにリストする必要があります。

バックアップの種類によっては、スクリプト（データベースなど）で簡単に復元テストできるものもあれば、手動入力（Active Directoryの復元）が必要なものもあります。これをできる限り自動化し、ある種の報告が行われていることを確認し、「誰か」が定期的に手動テストを実行することも確認してください。隔離された環境（prodのダウンスケールコピー）により、復元テストの実行が容易になります。

バックアップのテストは行っていませんが、BackupRadar.comで開発したシステムには、一元化されたバックアップチェックおよびレポートコンポーネントがあります。自由にチェックして、そのコンポーネントに役立つかどうかを確認してください。成功/失敗の電子メールのコピーをバックアップポリシーに添付し、バックアップソフトウェアもスクリーンショットを送信できる場合は、スクリーンショットも添付します。

ありがとう、パトリック

バックアップアクティビティがログに記録されていることを確認してから、（もちろんperlで）それらのログを解析して障害を探し、それを蒸留し、毎日の電子メールとして送信します。