ディザスタリカバリ計画のファンダメンタルズ：テストの基礎的要件

災害復旧計画を策定する前に、RTOとRPOを決定せよ

策定した災害復旧計画の妥当性を確認するために必要不可欠な要素。それは、災害復旧のプロセス全体を包括するテストだ。

公開 2011年05月30日 08時30分

更新 2014年12月12日 15時56分

著者

James Damoulakis

[TechTarget]

印刷する

　災害復旧（DR）計画を成功させるために欠かせない基盤の1つが、事業の要求定義を理解することだ。会社が必要とするものは何か。そして機能とコストの観点から、それらのニーズに対応することは可能か？　そのパフォーマンスを図る重要な数値となるのが、目標復旧時間（RTO）と目標復旧地点（RPO）だ。簡単に説明すると、RTOはオペレーションを復活させるまで（データ復旧だけではない）の最長許容時間であり、RPOはデータ損失の最大許容範囲だ。

　クリティカルなアプリケーションに対して、これらの数値を正しく理解し、関係者の間で合意できなければ、つまりそれらをサポートする環境への投資や開発に失敗すれば、業務部門とIT部門との間で災害復旧に対する認識に大きなギャップが生まれる。それを避けるためには、IT部門が業務部門やアプリケーションの所有者側と十分に議論し、彼らの復旧ニーズを正確に理解する必要がある。そうすることで、被災時の経済的損失を見極め、必要なサービスレベルを提供するためのコスト計算が可能になる。そのためにも、ここでは交渉力が不可欠だ。議論なくしてDRの成功はおぼつかない。

　それらの手順は情報テクノロジーの範囲を超えるが、まずは計画立案、そして相互依存性の特定、プロセスの開発があり、それらを踏まえた上でしっかりとしたテストを行わなければならない。

計画の失敗は深刻な事態に

　DR計画は、組織が被災したとき、いつ、どこで、何をすべきかを詳細に示すロードマップだ。そこには災害の前、災害の間、災害の後に実行すべきアクションが含まれる。また、災害であると判断する基準、被災を判定する責任者、その告知方法なども、基本的な要素として欠くことはできない。過去に起きたハリケーン関連の災害では、コミュニケーションの重要性が浮き彫りになった。優れた計画を立案するためには、例えば電子メールが機能しない、あるいは携帯電話サービスが利用できない、といった偶発的な事故もまた想定しておく必要がある。

　プロセスと手順は文書化しておかなければならない。それは分かっている。しかし、ほとんどの人は文書化に後ろ向きだ。万全を期して慎重に作成されたDR計画であっても、適切な配慮に欠ければ無意味なものとなってしまう。システムを修正するときやソフトウェアにパッチを当てるとき、あるいは追加のストレージを割り当てるときなど、DR計画への影響を自動的に検討するように、災害復旧は標準の変更管理プロセスに組み込まれるべきだろう。同じように、組織再編が行われたときも、DR計画は再検討されなければならない。

　データ量が2桁成長を続けていれば、いずれRTOの制約内でのデータ復旧が困難になることは明らかだ。しかし、アプリケーションの複雑性や相互依存性も、同様に復旧の大きな障害要因であるにもかかわらず、しばしば見過ごされがちだ。今日、メジャーなアプリケーションは複数のサーバやアーキテクチャにまたがって存在する。もはやメインフレームのアプリケーションがUNIXやWindowsプラットフォーム上に存在するアプリケーション、あるいはサブコンポーネントにデータを供給する時代ではない。伝統的なサーバ中心の復旧手法をベースとする場合、アプリケーションのコンポーネントごとにバックアップやスナップショットを取るのは可能だが、多様なコンポーネントにまたがる非一貫性を考えれば、アプリケーションを完全復旧するのは困難だ。

　だが、アプリケーション間の相互依存性を理解し、適切なデータ保護アプローチを適用すれば、この問題を回避できる。その場合、独立したエレメントを包含する一貫性グループ機能を持ったスプリットミラー／レプリケーション技術や、継続的データ保護（CDP）技術などの手法を用いればよい。