危機的状況下の実施に備えた災害復旧プランの検証を：ぶっつけ本番は厳禁

バックアップは取ってあっても、よく調べてみると、何かが足りないことに気付くかもしれない。

[Russell Olsen，TechTarget]

　IT災害復旧プランの検証に当たり最も重要な2つの要素は、現状に沿った計画を保つこと、および危機的状況の中で実際に定めた通りの計画を遂行できるかどうか検証することだろう。

　理想的なのは、毎年オフサイトで災害復旧担当チームにバックアップテープと新しいハードウェアのみを与え、会社のシステムを再建・復旧させてみることだ。しかし残念ながら、ほとんどの会社では、毎年災害復旧プランの完全な検証を実施できるほどの余裕はない。また実行できたとしても、それを補うためにすべきことはある。

　午前2時に上司に電話して、「すみませんがDFS共有フォルダに大切なファイルを保存しているユーザーの認証を忘れました」と言わなければならない事態は、どうしたら避けられるのか。

　災害復旧プランの検証には主に4つの要素がある。そのうち2つは、ソースファイルの特定と口頭によるプランの確認だ。残りの2つ、既存のプロジェクト利用と自分の過ちから学ぶことについては第2部「失敗から学ぶ災害復旧プラン検証」で解説する。

ソースファイルの特定

　ソースファイルの特定は、災害復旧プランの根本となるコンセプトだが、適切に対処されていない場合が多い。災害後の復旧に必要となる全ソフトとプロプライエタリアプリケーションのコピーの仕方が分かっているだろうか。自信過剰な向きは「バックアップを取ってある」と答えるだろうが、「本当に？　今すぐここでコピーできるか？」と問い返してみたい。

　ほとんどはバックアップを取ってあるが、手元にあるバックアップをよく調べてみると、何かが足りないことに気付くかもしれない――データベーススキーマ、ストアドプロシージャ、ファイアウォールのルールセット、DFS共有などが。DFS共有では、ユーザーが全ソースファイルを正しいディレクトリに保存しているだろうか。あるいは基本的なものを見落としている可能性もある。例えばMicrosoft Windows Server 2003のコピーを持っているだろうか。

　サーバイメージやバックアップに失敗し、最初からやり直すためにコピーが必要にならないとも限らないのだ。

　カスタム版のLDAP検索スクリプト、VBScript、Windows Server 2008とExchange Server 2007用のPowerShellスクリプトなど、自分たちが使っているさまざまなツールを社外でバックアップしてあるかどうか、チームのメンバーに確認することも忘れてはいけない。

関連ホワイトペーパー

Windows Server | ディザスタリカバリ | バックアップ