バックアップチェックのベストプラクティスは？
管理者が自動バックアップ用のシステムを作成し、それを忘れてしまうのはよくあることです。システムに障害が発生した後でのみ、管理者はバックアップシステムが以前に壊れているか、何らかの障害のためにバックアップを復元できず、復元する現在のバックアップがありません...では、このような状況を回避するためのベストプラクティスは何ですか？
ファイアドリルを実行します...数か月ごとにXYZシステムがダウンしていると言うのは良い考えです...それから実際にそれを新しいVMなど）にオンラインに戻す動作を実行します。それは物事を正直に保ち、あなたが間違いを見つけるのを助けます。
ソープボックスモード：オン
定期的にテストされていないバックアップは価値がないほど単純だと思います。
私の以前の仕事では、すべてのシステム（本番、テスト、開発の監視など）を6か月ごとにテスト復元するというポリシーがありました。
これは、ドキュメントが最新であるように、最も若い管理者の仕事でもありました。ジュニアは、彼/彼女が特定のシステムでどれだけの仕事をしたかによって定義され、いつか（実際にはかなり頻繁に）それをしたのは「グループマネージャー」でした
復元されたホストで実際に何も実行する必要がなかったため、これ専用の特別なハードウェア（1つのIntelと1つのIBM/AIXボックス）があり、ディスクスペース以外はすべて低スペックでした。
最初の数ラウンドはかなり多くの作業が必要でしたが、バックアップの重要な部分である復元プロセスを合理化することになりました。
管理者がバックアップジョブが「中断」したことに気づかず、動作中のバックアップが正しく機能しなかったという事実に言及しているように思われるので、バックアップの周りに何らかの監視スクリプトを作成することをお勧めします。
自社開発のバックアップソリューションを構築するとき、私は次のようなことをします。
- データをバックアップするスクリプトを作成します。
- テスト復元を実行して、スクリプトが正しく機能することを確認します。
- スクリプトで、または他の方法で、バックアップのステータス（成功、失敗、実行、実行されなかった）を追跡する方法を実装します。
- その追跡ステータスを監視します（電子メール、データベースなど）
それがすべて終わったら、大丈夫です。追加の1つのことは、定期的なテスト復元を実行することです。あなたがそれである原因に寄付するために余分なハードウェアを持っているならば。
私が働いている場所にはウォームサイトがあり、月に1回、システムまたはデータベースをランダムに選択してウォームサイトに移動し、ベアメタルでテスト復元演習を実行して、データを回復できることを確認します。
正直なところ、データが非常に重要である場合は、バックアップを管理するためのソフトウェアに投資することが最善の利益になります。安価でシンプルなものからエンタープライズクラスまで、このための製品は何百もあります。
会社のバックアップをcrontabで実行している一連の手書きスクリプトに依存している場合は、遅かれ早かれやけどを負う可能性があります。
「本番」システムの60％サイズの「リファレンス」バージョンがあり、変更の最終テストに使用し、「本番」バックアップをこれらのシステムに復元します。バックアップをテストし、両方の環境が互いに整合していることを確認します。 。
テスト復元を実行するとき、「これは見栄えが良く、ファイルが復元され、ファイルが欠落していないようで、サイズが一致していても」、または「これは見栄えが良いので、アプリケーションを起動しました」という時点では、あまり快適ではありません。 ..クラッシュせず、まともなデータを表示します。」.
サーバー/クラスターを最初から復元して、実際に本番に使用したいと思います。 1分ではなく、1時間ではありませんが、永続的に。復元が成功したと主張する場合、本番環境を開始しない理由はまったくありません。これは「汚い」システムではないので、忘れてください。これは、実際の災害の後に直面するシステムです。それで、それが「見栄えの良い」段階を通過するならば、それと一緒に住んでください。次の夜それをバックアップします。元のものを忘れてください。あなたはおそらく意志このアプローチを使用していくつかのグリッチを発見し、強制からそれらすべてを修正になります。同じシステムの次の復元には、100％成功する可能性が十分にあります。
これには、バックアップソフトウェアとサーバーが含まれます。はい、これらも復元する必要があります。
復元専用のハードウェアを購入する予算がありませんか？
- 絶対に予算が必要だということを強調してください。毎回、意思決定者に、完全な復元テストがまだ行われていないことを思い出させてください。 （そして、はい、あなたのお尻をカバーする証拠を集めてください。厳しい世界。）
- ほとんどの組織では、あるシステムを別のハードウェアに移行する必要がある場合があるため、この機会を利用してください。元のハードウェアを紛失したばかりのふりをして、移行には常に「バックアップから復元」方法を選択してください。はい、それはより多くのダウンタイムを意味します、それについて申し訳ありません。少なくとも、バックアップが役立つと確信できます。
- 移行はありませんか？たぶん、いくつかのハードウェアを2週間借りて、2つの復元テストを実行できます（借りたハードウェアに復元し、1週間以上待って、借りたものから元の状態に復元し、そのまま使用します）。通常、新しいシステム用に購入した新しいハードウェアがあり、適切に配置すれば、2週間徹底的にテストすることを提案することで、簡単に借りることができます。新しいハードウェアが古いハードウェアと100％同一でない場合は、テストがさらに改善されます。実際の災害の場合に同じハードウェアを入手できるかどうかをどうやって知るのですか？
- 現在、新しいシステムが実装されていますか？今すぐ復元をテストできますか？追加のハードウェアを使用しないでください。新しいシステムをすばやく再実装する方法についての新しい知識があるため、新しいシステムを上書きするだけです。これは、重要なデータがまだない場合に機能します。繰り返しますが、新しく再インストールされたバージョンではなく、復元されたバージョンで本番環境に移行します。
- 消防訓練。
- 6か月ごとにすべてのバックアップをテストするというポリシーは非常に良い考えです
- テストに関しては、バックアップする各アプリケーションまたはシステムを確認する必要があります。理想的には、「成功」または「回復可能」バックアップを構成するものを、バックアップのサービスの説明またはSOP（運用ドキュメント））に、保持時間、bladiblaなどの他の詳細とともにリストする必要があります。
一部のバックアップタイプはスクリプト（データベースなど）で簡単に復元テストできますが、その他の種類は手動入力（Active Directory復元）が必要な場合があります。これを可能な限り自動化し、何らかのレポートが作成されていることを確認し、「誰か」が定期的に手動テストを実行することも確認します。分離された環境（prodのダウンスケールされたコピー）により、復元テストの実行が容易になります。
1つのアプローチは、定期的に実行する「回復」ジョブをスクリプト化することです。たとえば、最新のバックアップから特定のテキストファイルを取得し、その内容を電子メールで送信します。可能であれば、データを作成またはバックアップしたボックスとは別のボックスを使用して、これを実行する必要があります。これは、必要に応じて機能することを確認するためです。利点は、暗号化/復号化、圧縮、およびストレージのメカニズムがすべて機能していることを確認できることです。
これは、電子メールサーバーやデータベースサーバーなどの特殊なバックアップにはもう少し複雑ですが、小さなDBまたはブリックレベルのメールボックスバックアップから何らかの小規模なリカバリを実行し、内容を確認することは確かに可能ですが、もう少し複雑です。
このアプローチでは、緊急時にデータを確実に回復できるように、定期的な完全復元に取って代わるべきではありません。これにより、日常のバックアップジョブの整合性についてもう少し自信を持てるようになります。
バックアップのテストは行っていませんが、BackupRadar.comを開発したシステムには、一元化されたバックアップチェックおよびレポートコンポーネントがあります。それがそのコンポーネントに役立つかどうかを確認するためにそれをチェックしてください。成功/失敗の電子メールのコピーをバックアップポリシーに添付し、バックアップソフトウェアがそれらを送信できる場合はスクリーンショットも添付します。
ありがとう、パトリック