ディザスタリカバリ・システムを構築するに当たっては，そのRPOとRTOを明確にすることが第一。そのうえで，アプリケーションやデータベース，ストレージなど，どの層でデータを連携させるかといったアーキテクチャを適切に選びたい。
災害時にもビジネスを継続するためには，リモートサイトにデータをバックアップするディザスタリカバリ・システムを構築する必要がある。Part4では，ディザスタリカバリ・システムの要件定義で考慮すべきRPO（Recovery Point Objective）とRTO（Recovery Time Objective），およびディザスタリカバリのアーキテクチャについて解説する。
まずはRPOとRTOを明確にする
ディザスタリカバリ・システムでは，災害発生時にデータを回復してシステムを再開させる。そこで求められるRPOやRTOは，システムの特性により様々である。
ディザスタリカバリ・システムの設計においては，どの時点のデータをいつまでに回復すればよいかを明確にすることが重要だ(図1)。
どの時点までのデータを回復するかを定めた指標がRPO。例えば，1日前までのデータが回復できればよいのであれば，バックアップデータを毎日リモートサイトに転送する方法でも対応可能である。しかし，データ損失ゼロ，すなわちRPO=0を目指すのであれば，更新データを同期コピーでリモートサイトに転送する必要がある。
一方，災害発生からシステムを復旧するまでに要する時間がRTOである。一般にシステムの復旧手順は，（1）代替機の手配，（2）システムの再起動，（3）データのリストア，（4）データの回復，（5）システム復旧確認，となる。RTOが1カ月以上の場合，リモートサイトにはデータのみをバックアップしておき，災害発生時に代替機を手配すればよい。しかし，RTOが数時間以内となると，リモートサイトに代替機をあらかじめ準備しておき，データを常にコピーしておく必要がある。
ディザスタリカバリのアーキテクチャ
ディザスタリカバリ・システムのアーキテクチャは大きく4種類ある(図2)。以下ではそれぞれの方式について解説する。
一つ目のアーキテクチャは，アプリケーション層でトランザクションを複製する。この方式では，アプリケーション・プログラムにトランザクションを複製する機能を実装するので，データ転送効率が高い。メインサイトとリモートサイトのアプリケーションが常時協調しているので，災害発生時のダウンタイムを最短化できる。
ただし，データ転送をAP(アプリケーション）サーバーで行うため，平常時のメインサイトのアプリケーション性能に影響を与える。また，リモートサイトのAP/DB(データベース）サーバーを常時稼働させておく必要があるので，システム構築・運用コストが高い。さらに，この方式で既存のシステムにディザスタリカバリ機能を追加する場合，アプリケーション・プログラムの変更が必須となる。
二つ目はデータベース層でログを複製するアーキテクチャだ。データベースシステムが提供しているレプリケーション機能を活用するので，アプリケーション・プログラムを変更する必要がない。また，この方式ではログのみを転送するため，データ転送量は少なくて済む。
しかし，DBサーバーでログ転送を行うので，平常時のデータベース処理性能に影響を与える。また，リモートサイトのAPサーバーは常時稼働させる必要はないが，ログを逐次適用する必要があるため，DBサーバーは常時稼働が必要である。
三つ目はストレージ層でデータを複製するアーキテクチャ。ストレージのリモートコピー機能を活用して更新データを常時転送する。トランザクション複製やログ複製の方式と比較して，データ転送量は大きくなるが，メインサイトとリモートサイトのストレージの内容が一致しているため，システム復旧手順が単純化できる。さらに，リモートサイトのAP/DBサーバーは，平常時は稼働させる必要がないので，リモートサイトの運用管理コストが低減できる。また，リモートコピーをストレージ層で行うため，AP/DBサーバーの処理性能への影響も小さい。
最後はデータベースとストレージを連携させたアーキテクチャである。ストレージでデータベースのログを複製し，リモートサイトのデータベースにログを逐次適用する。ログのみをストレージで転送するので，データ転送量を抑制でき，メインサイトのAP/DBサーバーの処理性能への影響も小さい。リモートサイトのAPサーバーも常時稼働させる必要はない。ただし，ログを逐次適用する必要があるので，DBサーバーは常時稼働が必要である。
これらの方式はいずれも一長一短がある。そのため，システムの要件に合ったアーキテクチャを選択することが重要だ。
データ欠損ゼロではサイト間の距離も考慮する
ここでは，データ欠損ゼロ，すなわちRPO=0のディザスタリカバリ・システムを構築する際の留意点に触れる。データ欠損ゼロを実現するためには同期コピーが必須となる。同期コピーでは，リモートサイトへのデータ転送が完了するまでメインサイトの処理を待ち合わせる。このデータ転送遅延時間は，サイト間の距離に応じて増大し，メインサイトの性能を低下させる要因となる。
一般に，同期コピーが適用可能な距離は100km以内とされている。これ以上の遠距離の構成では，複数のログやトランザクション情報をまとめて転送するなど，データ転送遅延時間の影響を最小化する工夫が必要となる。また，WAN最適化コントローラなどを適用し転送遅延時間を削減することも有効だ。
システムの要件によっては，データ欠損ゼロを保障する同期コピーのリモートサイトを100km以内の近郊に置き，災害直前のデータ欠損をある程度許容する非同期コピーのリモートサイトを遠隔地に置く3データセンター方式も有効である。
災害に備え定期的なテストを実施する
災害時にシステムを復旧するには，普段から，災害発生を想定した備えが必要だ。
SEC(米証券取引委員会）が策定したディザスタリカバリのガイドラインでは，システムの定期的なテストの実施を要求している。遠隔地にリモートサイトを配備した場合，リモートサイトで業務を引き継ぐための人員配置も決めておかなければならない。そのため，災害発生の判定から人員配置，システム復旧まで含めた災害復旧マニュアルを事前に準備しておき，関係者に周知徹底することが重要である。
