サービス復旧の視点から考える、バックアップツール活用術：IT導入完全ガイド（2/5 ページ）

バックアップはしてもリストアはしたことがない。では、操作ミス、機器障害、ウイルス感染、災害など、いざというときに通常の状態に戻すまでにどんな操作と時間が必要だろうか？

[土肥正弘，ドキュメント工房]

“数分”単位で復旧可能でデータ保護もできる「レプリケーション」

　クリティカルな業務では本番系サーバと待機系サーバで同じデータを持ち合い、障害発生時に本番系から待機系に処理を切り替える仕組みで最速数秒〜数十分程度でサービスが再開できるクラスタリングが利用されるが、ストレージを共有する場合にストレージ障害には対応できず、データ保護の観点からは不十分だ。

　データ保護ができてサービス停止時間を最も短くできるのがレプリケーション（複製）だ。これはサーバ（あるいはストレージ）の複製をできるだけリアルタイムに作成する仕組みだ。基本的には本番系サーバの中身を遠隔地の複製用サーバに絶えずコピーするので、データは同一のものを両方が保持する。

　本番系サーバに障害が起きたら、複製先サーバに処理を切替えて暫定運用し、本番系サーバの復旧後に暫定運用中のデータを加えて処理を戻す。HA対応のツールなら数分程度のサービス停止で済み、複製先サーバを遠隔拠点に置けば、災害対策にも有効、ストレージ装置の障害でもデータが復旧できる。

　従来バックアップとは異なる領域の技術だったが、現在ではバックアップ用ソフトウェアやバックアップアプライアンスが標準でレプリケーション機能を持つようになり、低コストに利用できるようになった。また、複製元と複製先の機器は同一構成とするのがこれまでの常識だったが、現在では異なるOSエディション（EnterpriseとStandardなど）や異ベンダーのハードウェア間でもレプリケーションを可能にするツールもある。

　バックアップアプライアンスは数TBの機種が多いものの、中には1.7PBまで拡張可能な製品も登場し、スケーラビリティーは十分だ。アプライアンスの長所はソフトウェアライセンス購入などの手間がかからず、導入や運用管理が容易であることだ。遠隔地でのアプライアンス間でレプリケーションが可能で、機種の容量に余裕があればお互いのレプリケーションを持ち合うこともできる。一方の拠点がダウンした場合でも、もう一方の拠点にあるレプリケーションを利用してサーバを復旧し、業務を引き継げる。

　一部のバックアップツールでは、設定された復旧ポイントでのサーバの状態を丸ごとコピーした仮想サーバを常に用意する「仮想スタンバイ」機能を備えるものがある。サーバ障害が起きたら処理を仮想サーバに切り替えて継続できる。平常時の物理サーバに比較して性能面が劣る可能性があるのでサービスパフォーマンスは劣る（縮退）かもしれないが、サービスを停止するよりは有利な選択だ。

　バックアップアプライアンスにも同様の機能を持つものがあり、アプライアンス内部で仮想サーバを構築し、物理サーバなしでも縮退運用が可能なBCP対策を主眼にした製品も提供される。

コラム：RLO（Recovery Level Objective：目標復旧レベル）という新しい視点

　仮想サーバを利用したサービスの縮退運用という選択肢ができて以降、RLOもツール選びのキーワードになった。これは一刻も早いサービス再開のために、100％のサービスレベルでなくてもいいから、サービスの完全停止に至るのを避けたい場合に重要な指標だ。

　例えば、完全復旧までに数日かかるとき、仮想サーバによる縮退運用を数分〜数時間後には開始して業務を始められる。そのサービス縮退のレベルを数値化するのがRLOだ。