災害復旧プランの検証──自分の失敗から学ぶ：なぜ失敗したのか？ 復旧にかかった時間は？

最高の災害復旧プロセスは、日常的な失敗の中にある。既存の出来事を活用して予想外の問題を検証すれば、大規模災害への備えは大きな前進を遂げる。

[Russell Olsen，TechTarget]

　IT災害復旧プランの検証には主に4つの要素がある。既存のプロジェクトを例として使うこと、自分の失敗から学ぶこと、ソースファイルを特定すること、口頭によってプランを確認することだ。後ろの2つについては以前取り上げた。

既存のプロジェクト利用

　どこの部署にも、災害復旧プラン検証を実地に組み込めるプロジェクトが必ずあるものだ。

　開始したばかりのプロジェクト、あるいはこれから実施予定のプロジェクトは、手っ取り早く災害復旧プランを検証する好機になる。こうしたプロジェクトは、新しいハードウェアの導入を伴う場合も多い。新しいハードウェアが意味することは2つある。まず、誰かが最初からサーバの設定をする（自分が再構築した手順をテストする絶好の機会が提供される）、そして、古いサーバの引退は、バックアップをテストして自分のサーバのイメージを再構築する絶好の機会になる。

　例えば自分の会社が別の会社を買収し、両社のユーザーとコンピュータを統合して自社のActive Directoryの組織単位（OU：Organizational Unit）に組み込むとする。

　適切なロールバックプロセスでこのプロジェクトの計画を立てれば、もともとあったOUのAuthoritative Restoreテストを実行し、自分の移行計画が適切かどうかを確認できる。プロジェクトは何日か長引くかもしれないが、（業務に影響を与えない）実地検証には、数日余分に費やすだけの価値がある。

　この方法で行う災害復旧プラン検証の要点は、自分が既にやっていることの活用にある。各所に手順を追加することにより、経費がかさむ社外でのテストを実施することなく、自分のプロセスを効果的に検証できる。

失敗から学ぶ

　IT災害復旧プラン検証を実施する場合、計画的な検証を行ってインプットをコントロールしなければ、結果に確証は持てないと思われがちだ。しかしわたしの経験では、最高の災害復旧プロセスは、自分たちの日常的な失敗の中にある。

　手違いは毎日のように発生する。新しいドメイン管理者がOUを削除してしまう、Microsoft SQL Serverのデータベース管理者がデータベーススキーマのバックアップを忘れる（そしてプロダクションデータベースが落ちてからそのことに気付く）、ハードウェアの問題でExchange Serverがダウンする、などなど。

　こうした日々の問題を好機ととらえて事後検証を行い、以下のことを問い掛けてみるといい。