一刻を争う状況で、
迅速に復元 

DRソリューションは、設定が容易で使いやすくなければなりません。災害のさ中にシステムの使い方を把握しようと四苦八苦する、などという事態に陥るのは避けたいものです。管理者やオペレーターからアプリケーションの所有者に至るまで、ステークホルダーがDRソリューションを利用するうえでは、使いやすくアクセスしやすいユーザーインターフェイスを備えていることが不可欠になります。

また、目標復旧時点（RPO）や目標復旧時間（RTO）をはじめとする主要メトリックスの検証を通じて、DRソリューションがコンプライアンス要件を満たしていることも極めて重要です。これらのメトリックスを常に満たしていると実証できることは、DRの最重要の側面の1つです。DRソリューションでは、これらのメトリックスを頻繁に、またはスケジュールに従って容易に検証できなければなりません。

さらに、DR計画に関する文書を動的に生成し、計画に加えられる変更の監査ログを提供できることも必要です。この文書は、カスタマイズしやすく、必要に応じて主なステークホルダーに自動送信できる必要があります。文書化はDR計画の最重要の側面の1つですが、見過ごされることが少なくないのです。

災害からの復旧は簡単なことではありません。企業の時間、資金、設備と人員が投じられますが、DR計画は、あらゆる組織にとって極めて重要な計画の1つです。災害による稼働停止に伴って生じる費用は、計画を立てる際のコストをはるかに上回ります。

DRソフトウェアは来るべきときに備えて、テストと文書化によって復元プロセスの合理化と自動化を行います。

DRのテストを毎年実施すべき理由は、数多く存在します。まず、DR計画が適切に機能するかどうかが明らかになります。計画が適切に機能していない場合、SLAの目標に届かない場合、問題が生じている場合は、必要な変更を計画に加えて、最も重大なタイミングで適切に機能するようにするための格好の機会となります。

テストを毎年実施するのも良いことですが、さらに頻度を上げて自動化する方が良く、復元の成功率も高まります。