ゼロからはじめるバックアップ入門 第7回

電電公社世田谷ケーブル火災や阪神淡路大震災の教訓による対策とは？

災害対策のためのバックアップを知ろう

バックアップセンターの利用

　最初に紹介した、電電公社世田谷ケーブル火災と阪神淡路大震災の2つの大事件は、バックアップデータの遠隔保管で迅速に対処できない事例でもある。前者は、データセンターとその中のコンピュータシステムは無事だったのに、通信回線が切断されたため、オンライン端末からアクセスができなくなった。こうなると、遠隔地に保管したバックアップデータの出番はない。

　後者では、データセンターの建屋やコンピュータのハードウェアが物理的に損傷したため、遠隔地に保管したバックアップデータをリストアする環境を構築することから着手しなければならかった。そのため、データセンターの補修や移転、およびハードウェアの再調達に数日から数週間の時間が掛かったケースもある。

　電力・ガス・水道などのライフラインや、金融機関などの社会インフラを支えるための情報システムは、被災した場合であっても迅速に回復できることが望ましい。上記の2つの大事件を想定すると、バックアップデータを遠隔保管するだけでなく、

• データセンターそのものをバックアップする
• バックアップセンターを遠隔地に設置する

という手段が有効だ。そして、バックアップセンターには、企業活動を維持するための最小限の業務を遂行するためのコンピュータシステム（バックアップシステム）を構築するのである。

　被災時のRTO（目標復旧時間）を短縮するため、バックアップシステムには本番システムのデータを、あらかじめリストアしておくことが一般的だ。以前の通信コストが高かった時代には、本番システムのデータをバックアップした媒体をバックアップセンターまで搬送し、それを利用してバックアップシステムのデータを更新しておく、という方法が用いられた（図2）。

図2　バックアップテープをバックアップセンターへ搬送し反映する

　本番系システムが被災した場合には、オンライン端末の接続先をバックアップシステムへ切り替えることで、業務を継続するのである。単にバックアップ媒体の遠隔保管する方法に比べて、RTO（目標復旧時間）が大幅に短縮されるのだ。

　ただし、この方法にも、以下のデメリットが残る。

1. 搬送中のテープの盗難や紛失など、情報漏えいのリスクがある
2. バックアップしてテープを搬送するサイクルが、もっともひんぱんな場合でもおおむね日次なので、RPO（目標復旧時点）は最小で24時間となる。つまり、リカバリしても直近の24時間か、それ以上のデータを失う

リモートレプリケーション

　前述の通り、バックアップセンターを設置したとしても、テープ搬送によりデータを受け渡している限りは、RPO（目標復旧時点）は1日以上前となる。銀行の預金残高などリアルタイム性が要求され、消失するデータが日単位になればビジネスに致命的な影響があるようなシステムでは、さらにRPOの短縮が求められる。

　そこで有効な手段が「リモートレプリケーション」である。レプリケーションは前回説明した通り、「ディスクボリュームやデータベースの完全な複製をリアルタイムで作成する技法」であり、そのレプリケーションを遠く離れた地点に設置された装置間で行なうのがリモートレプリケーションだ。

　インターネットの普及などにより、この10年ほどの間、高品質で広帯域の通信回線の価格低下は目覚しいものがある。その下落幅は、第6回で言及したHDDの価格低下と双璧をなす。この回線コストの低下が、リモートレプリケーションの前提であり、普及の推進力となっている。

　リモートレプリケーションの実装には、

1. Oracleなどのデータベースアプリケーションの機能として動作させる
2. サーバーのミドルウェアの機能として動作させる
3. ストレージ装置の機能として動作させる

　の3種類がある。

　1ではリモートレプリケーションの対象は、あくまでそのデータベース（アプリケーション）だけである。2ではサーバーのすべての論理ディスクが動作の対象となるが、サーバーに負荷がかかる（負荷の点では1も同じ）。また、3はストレージ自身の機能であるため、データの種類を問わずレプリケーションが行なわれ、かつサーバーに負荷がかからない。

　また、リモートレプリケーションには、同期モードおよび非同期モードという2種類の動作がある（図3）。同期モードでは、ローカル側への書き込み要求（ディスクやストレージ装置へのI/O）は、リモートへの転送とリモート側の更新が完了してから、要求元のアプリケーションやサーバーへ処理の完了が通知される。同期モードでは、ローカルとリモートのデータは完全に一致するが、拠点間の距離が長くなるほど回線の伝送遅延が大きくなり、システム全体として動作が遅くなる。そのため、WANを介したリモートレプリケーションでは、同期モードは現実的ではない。

図3　リモートレプリケーションの同期モードと非同期モード

　WANを介したリモートレプリケーションでは、非同期モードが採用されることが多い。非同期モードは、ローカル側の更新処理が完了すれば、要求元のアプリケーションやサーバーへ処理の完了が通知される。このため、回線の伝送遅延の影響を受けずに済み、動作は遅くならない。しかし、伝送遅延はあるので、ローカル側とリモート側との間でデータ更新の「時差」が生じる。その結果、災害時にはリモート側に最新のデータが反映されず、消失してしまう可能性がある。

　同様に、回線障害が発生すれば、ローカル側とリモート側のデータが一致せず、不整合な状態になる。これへの対策としては、リモート側だけ、またはローカル側・リモート側の両方で、定期的にスナップショットを取得するという方法がよく使われる。