限られたテストリソースでテストを復元するにはどうすればよいですか？
リソースが限られている小規模な組織では、データバックアップシステムの復元テストをどのように実行しますか？
「バックアップをテストしてください！」メインラインシステムに影響を与えることなく、本格的な復元テストに含まれる現実に直面すると、非現実的に見えます。
組織には、夜間のバックアップが復元可能であることを確認するために、完全なテスト環境の一時的なスピンアップを割り当てるために、数万ドル相当の予備サーバー容量がないことを前提としています。
毎年の復元テストを行うために、すべてのメインラインハードウェアをもう一度購入することを正当化する方法はありますが、それ以外の場合はストレージに保存され、電源がオフになって使用されていませんか？
メディア復元テストに関する他のサーバー障害の説明では、別のテープドライブを使用して、メディアが別のデバイスで使用可能であることを確認することが提案されています。
数台のサーバーと単一の実稼働テープドライブしかない小規模なサイトの場合、追加のLTO-7テープドライブを数千ドルで購入し、それに合わせてバックアップソフトウェアの追加ライセンスを購入することを正当化するのは難しいようです。年に1回のメディア復元/テスト環境の検証プロセスを棚に貼り付け、翌年のテストプロセスまで使用しないでください。
バックアップを主にテストするのは復元手順をテストする危機的な状況にあるときは何をすべきかを正確に把握し、誰もがパニックになるときは有能で自信があり、落ち着いていてそれまでにバックアップを復元することは日常的なイベントであるため、何をすべきか、復元にかかるおおよその時間などを正確に把握します。
おそらく2番目にやりたいことはテストデータの整合性です。重要なデータを復元したら、本番環境を再開できますか？破損したものや不完全なものはありませんか？
一度に1つの小さなピースで、これらの両方をテストすることができ、おそらくテストする必要があります。基本を理解した後でのみ、データセンター全体の復元を試みる必要があります。
たとえば、ファイルシステムとネットワーク共有のバックアップを作成する場合、適切なテストは、特定のディレクトリを別の場所に復元し、ファイルサイズ、ハッシュ、およびアクセス許可を元のディレクトリと比較することです。
次回テストのためにデータベースのクローンを作成する必要があるときは、代わりにバックアップから本番データベースを復元します。
必要に応じて、VM）で「ベアメタル」OS復元を実行します。
ただし、バックアップと復元は、より大規模なディザスタリカバリ戦略と事業継続計画の1つの側面にすぎません。
自然災害（火災、洪水、ハリケーンなど）により現在地が失われた場合、あなたのビジネスはどうなりますか？それは他の既存の場所から運営を続けることができますか、それともあなたが唯一の場所ですか、ビジネスは単に破産しますか、それとも保険金は緊急オフィス/コンテナを借りるために使用されますか？
これは、数年前のある会社でのBCP戦略でした。HPまたは当時のIBMとの契約で、データセンターの完全なディザスタリカバリテストのために年に1回コンテナでデータセンターを提供し、それをスタンバイ状態にすることもできました。急性災害の場合。
その会社には1つのオフィス施設があり、テープだけがオフサイト（またはテープロボット）であり、その他はすべて社内にありました。仮設の家具付きオフィススペースのレンタル、インターネット接続の取得、電話番号の再ルーティング、デスクトップやプリンターの取得などは、ほとんどが商品であり、手配が簡単であるという考えでした。しかし、ITは少し少ないです。ツインデータセンターの費用便益計算は不利でした。
そのため、最初は6か月ごと、その後は1年に1回、完全なBCPテストを実行しましたが、一時的にレンタルしたハードウェアで、VMWareの展開、バックアップサーバーの復元、ADドメインコントローラー、メールサーバー、データベース、アプリケーションサーバーを使用したVMの復元を行いました。およびファイル共有。
より現代的なBCP戦略は、クラウドベースであり、オフプレミスのバックアップコピーをオンラインで使用し、DR復元をクラウドでテストすることもできます。必要なのが数日だけの場合は、かなりの数のVMは銀行を壊すことはありません。
古い格言を言い換えると
災害は確実です、復元します-完全ではありません
つまり、バックアップおよび復元テストは絶対に必要です。適切なバックアップと復元の計画を立てるために、次の点を強調したいと思います。
- 定期的な復元真の必要性です。経営陣は、直接的な即時の利益がないものはすべて不要であると見なしているため、これは多くの場合最も難しい部分です。悲しい現実は、彼らのデータが危険にさらされているということです。彼らは、関連するコストはあるものの、定期的な復元は価値のある投資であることを理解する必要があります。
- あなたの側では、バックアップを保存するために独自のバイナリブロブを避けるに非常に努力してください：それらはほとんど検査できず、部分的な回復の可能性をほとんどまたはまったく提供しません。オープンで検査可能なファイル形式（
tarなど）を強くお勧めします。または、rsync（または同様のツール）を使用して、データのファイルシステムレベルのバックアップを作成することを強くお勧めします。このようなツールを使用すると、バックアップを非常に簡単に検査して、すべて（またはほとんど）が存在する/アクセス可能かどうかを一目で把握できます。 - 高速復元の場合、重要な仮想マシンのバイナリイメージを作成してみてください（スナップショット経由）。これには、互換性のある仮想化ソフトウェアを搭載したワークステーションにインポート/起動するだけですぐに検査できるという追加の利点があります（現在、すべての主要な仮想化プラットフォームには、この種の「安価な」復元に非常に適した無料の試用版があります）
- データベースの場合、適切なダンプツールを使用して仮想マシン内に復元します次に、復元されたデータベースを使用し、アプリケーションが機能するかどうか、および最近のデータかどうかを確認するために簡単な検査を行うように1人のユーザーに依頼します（すなわち：昨日）が存在します
- バックアップと復元の手順が機能する場合、文書化：何か問題が発生した場合は、非常に明確な運用計画に従う必要があります。これにより、ストレスが軽減され、成功の可能性が高まります。
迅速で費用効果の高い復元を行うには、一時的な仮想マシンを十分に活用し、安価なハードウェア（廃止されたサーバーまたはワークステーション）で実行することが重要です。ディスク容量が問題になる場合は、シンプロビジョニングを幅広く使用してください。利用可能な場合RAMが問題である場合は、毎回小さなVMサブセット（単一のものでも）のみを復元します。
For a small site with only a few servers and a single production tape drive, it seems hard to justify buying an additional LTO-7 tape drive for thousands of dollars and additional licensing for the backup software to go with it, just to use it for a once-per-year media restore / test environment verification process and then stick it on a shelf and don't use it until next year's test process.
ほとんどの企業は実際にはそうしていません。その理由は、万が一、完全かつ壊滅的な損失が発生した場合にバックアップハードウェアの交換が必要になった場合に、必要なハードウェアを購入して数時間以内に（価格で）入手できると想定しているためです。したがって、計画には、予備のバックアップハードウェア、ソフトウェア、ライセンスなどの購入を必ずしも含める必要はありません。