今回は災害対策について取り上げる。災害対策は事業継続のために行うものである。そのため情報システムのみならず，それを支えるファシリティ（データセンターや電源，空調，空調用の水など），運用のための人員，情報システムにより統制される業務プロセスのほかの系（工場，流通など）などを含め，総合的視点で対策を立てる必要がある。情報システムで統制するほかの系も同時に被災するような場合，システムのみの災害対策では不十分となる。情報システム以外の対策も重要だという認識のうえ，ここでは，ITアーキテクトとしての災害対策ということで，情報システムに焦点を絞ることにする。

　情報システムの災害対策も広義のバックアップなので，リカバリ要件の中心となるRTO（目標復旧時間），RPO（目標復旧時点）により決めていくことになるが，前述したように総合的な判断によりRTO，RPOを決めるようにしたい。ここから先はRTO，RPOを別々に検討していくことにしよう。

RTO要件ごとの災害対策

[要件]秒～分単位のRTO　[対策]広域クラスタリングによる自動切り替え

　秒～分単位でのRTOが必要ということは，被災により障害が発生したシステムからバックアップ用システムへの切り替えを自動で行う必要があるということになる。具体的には，「広域クラスタリング技術」を用いて，バックアップ・システムへの自動的な切り替えを行うことになる。

　広域クラスタリング技術は，一般的な高可用性クラスタリング（あるいはローカル・クラスタリング）と異なる。その一番の違いはネットワーク部分の処理にある。ローカル・クラスタリングでは同一のネットワーク・セグメント上にバックアップ・システムを構築する。プライマリ・システムに障害が起こった場合，プライマリ・システムのIPアドレスをバックアップ・システムが引き継いで動作する。そのためそのシステムを利用する他のシステム（あるいはクライアント）はバックアップ・システムに切り替わったことは一般的には分からないことが多い。

　一方，広域クラスタリングでは同一のネットワーク・セグメントを利用することはほとんどなく，バックアップ・システムへの切り替えはIPアドレスの変更が必要となる。これはDNSの動的更新機能を使用して実施する。この場合に，切り替わったバックアップ・システムに，クライアントからネットワーク経由で継続してアクセスできることが重要である。

[要件]数時間程度のRTO　[対策]クラスタリング＋手動切り替え

　分単位より長い時間のRTOの場合，バックアップ・システムへの切り替えは自動ではなく，手動で切り替える方法をとることが多い。ここで注意が必要なのは，切り替えの判断を誰かが確実に行う必要があるということだ。

　バックアップ・システムは，プライマリ・システムと同じスペックのマシンを用意しない（または，できない）ことがあるので，こうしたケースでは，プライマリ・システムと比べて性能が低いバックアップ・システムに切り替えた方がよいか，それともプライマリ・システムを復旧させた方がよいかを判断することになる。

　こうした判断を行うには，RTOとして数十分ではなく数時間という時間が必要になる。実際には，災害発生→安否確認→被害調査→切り替え／復旧判断→切り替え実施というフローになることが多いからだ。また，システムが被災していることは監視により容易に把握できるが，被害の状況と復旧時間の見積もりには時間がかかることもあるので，調査や判断に一定以上の時間がかかると見込まれるときには，どこかのタイミングで「切り替え」を選択し，システムの復旧を優先させることが必要となる。

[要件]数日程度のRTO　[対策]バックアップ・データからのリストア

　システムを復旧するまでに数日間の時間の余裕が取れる場合，バックアップ・データをリストアする方法を取ることができる。また，バックアップ・データをバックアップ・サイトに置いておく必要があるが，数日程度のRTOなら，ネットワーク経由でのデータ転送でなく，バックアップ・テープを輸送する方法でも可能であろう。

[要件]1週間以上のRTO　[対策]システム再構築

　もし，1週間以上のRTOとよい場合，被災後に，バックアップ・システムそのものを構築することも可能となる。この場合，バックアップ・データの準備に加え，被災後ただちに構築作業を開始できるような準備が必要となる。例えば，ハードウエア，ソフトウエア，構築手順，構築のためのスタッフなどである。