この投稿で、彼はバックアップのテストの歴史について語ることを約束しました。 今日はそれだけです。 不愉快な驚きを伴わずに、そして既に刺激的なデータ損失の瞬間に、バックアップをテストする必要があります。 さらに、バックアップファイルの整合性のチェック（バックアップファイル内のデータブロックのチェックサムのチェック）ではなく、復元されたものの操作性をチェックする際の本格的なテストリカバリについて説明します。
バックアップファイルの何が問題なのか
バックアップファイル自体が破損している場合に加えて、バックアップコピーからの復元に失敗する多くの技術的および組織的な理由があります。 私は出会ったものに専念します。
すでに破損したデータ/ファイルはバックアップされます。 サーバー上でディスクが崩れ始めました。 監視が機能しませんでした。 一部のファイルは不良になりましたが、安全にバックアップされました。 このような問題は、目的のファイルを開くまで何週間も見過ごされる可能性があります。 リカバリプロセス中に、バックアップ内のファイルも非アクティブであることがわかります。
一貫性のないバックアップ 。 これは、間違ったバックアップツールを選択した場合に発生する可能性があります。 たとえば、データベースが仮想マシンで実行されており、管理者がバックアップのために、アプリケーション整合性バックアップをサポートせずにVMバックアップを使用することを決定しました。
実際、データベースは作業中にRAMのキャッシュを積極的に使用し、データの一部がそこにあります。 DBMSはデータをディスクに書き込み、データがいつでも一貫するようにします。また、サーバーが突然シャットダウンしても、データベースが無駄なバイトセットに変わることはありません。 バックアップシステムはデータを即座に記録せず、キャッシュをファイルシステムと同期することについて何も知らないため、バックアップ時にデータの一部が間違った順序で書き込まれる可能性があります。 次に、VMを復元した後、破損したベースが取得されますが、その一部は互いに対応していません。
特別なバックアップエージェントを使用する場合、これは起こりません。
作業バックアップがありますが、ありません。 これは非常に一般的です。システムのライフサイクルはほぼ次のとおりです。システムを作成し、バックアップ用に設定するからです。 その後、遅かれ早かれ、システムアーキテクチャを変更し、サーバー、ディスクを追加/削減し、名前を変更し、バックアップの隣に復元し、バックアップポリシーに変更を反映するのを忘れました。 したがって、バックアップは必要なものではないことがわかります。
テストする理由
答えは簡単だと思われます。バックアップから確実に回復できるようにするためです。 しかし、いくつかの重要な組織上の問題があり、それを自分で明確にするとよいでしょう。
Real RTOを理解する。 投機的評価は現実とは異なります。 特に、リカバリプロセス全体がバックアップからのデータまたはアプリケーションの展開に限定されない場合。 回復する前に、何をどこで復元するかを理解する必要があります。 リカバリ後、システムは常にすぐに使用できる状態になるとは限りません。手動設定が必要になる場合があります。 その後、復元されたシステムの操作性を確認する必要があります。 バックアップがオフィスの外のテープに保存されている場合は、バックアップがオフィスに配信されるまでの時間を理解する必要があります。 これはすべて、回復時間または回復時間までの時間を増加させます。
したがって、ドアからドアへの復旧パス全体を見ると、RTOは単なる「クリーンな」データ復旧速度以上のものを獲得する可能性があります。
誰が何をしますか。 テストの復元中に、機器だけでなく、人、プロセス、規制（存在する場合）の作業もテストされます;これは、弱点を特定し、適切な人がいない場合に何をするかを考える機会です。
修復に関与する人が多いほど、そのような軍事演習が必要になります。
テスト方法
テストの頻度。 バックアップシステムをセットアップしたら、そこにバックアップがあることを少なくとも1回確認し、復元を試みます。
さらに、チェックスケジュールは、アプリケーション/データに対する変更の頻度、特定のデータの重要性、テスト用のリソースに基づいて、開発者などのサービス所有者によって決定されます。
災害およびバックアップからのリカバリのさまざまなシナリオ。 想像力を有効にして、バックアップから復元する必要があるさまざまな理由を考えてください。 ですから、装備、プロセス、戦闘状態にある人々をチェックし、真空状態で球体回復を行わないでください。 このための脅威モデルを概説すると便利です。 オプションとして：
- ハードウェア障害：故障したドライブ、ソース情報を持つサーバー。
- ソフトウェア障害：更新の失敗、ウイルス。
- 人的要因：管理者が目的のファイルを削除しました。
これらの各ケースでは、別のボリュームでリカバリする必要があります。別の場所にあるファイルと、すべてを展開する場所です。
必ず自宅のコンピューターからリモートで回復してください。 結局のところ、障害は営業時間中だけでなく発生します。
また、次の2つのステップのアクションを検討してください。リカバリ中にバックアップがzilchまたはリカバリに失敗したことが判明した場合、次に何をしますか。 テスト中に最後のバックアップが機能しないことが判明した場合は、可能であれば順番をずらして新しいバックアップを作成するか、同僚に次のバックアップサイクルまで可能な限り慎重に作業するよう警告します。
さまざまな時点から回復します。 どのバックアップが必要かはわからないので、テストするときは、異なる復旧ポイントから復旧してみてください。 そのため、たとえば金曜日のバックアップだけでなく、水曜日に何をするのかなど、すべてが揃っていることを確認します。 サンプルが大きいほど、バックアップのパフォーマンスを心配する理由が少なくなります。
回復手順を文書化します。 あるオフィスで、バックアップからのリカバリをテストするために次のアプローチを使用していることを読んだことがあります。 次に、結果に応じて、回復したかどうかを確認し、指示の関連性について結論を出します。 戦闘演習中にこのような極端に進む必要はありませんが、特定のシステムを復元するために必要なすべてのアクションを規制やその他の文書に記録しておくといいでしょう。
これは、システムの責任者が一時的に利用できない場合に回復プロセスを開始できるようにするために行われます。
また、システム回復に必要なすべての情報（構成設定、ライセンスキー、パスワード）が不在の管理者の頭にあるだけでなく、電子形式で複製され、and索好きな目から安全に保管されることを確認する必要もあります。
念のため：生産性を損なうことなく、 個別のサンドボックスでリカバリをテストします。