「あらゆる災害に備えた完璧な対策」なんて無理：ディザスタリカバリで強い企業を作る（1/2 ページ）

大がかりでコストのかかるプロジェクトと見られがちだが、適材適所の「見極め」によって効果的なディザスタリカバリが実現できる。

[渡邉利和，ITmedia]

本記事の関連コンテンツは、オンライン・ムック「ディザスタリカバリで強い企業を作る」でご覧になれます。

リソースについての考察も

　前回説明したように、ディザスタリカバリ（DR：Disaster Recovery）の実現に向けてデータの保護について十分な検討を行ったら、続いてシステムリソースの保護についても考えておく必要がある。

　具体的には、サーバやストレージといった、ITシステムを構成するハードウェアや、OSやアプリケーションといったソフトウェアの復旧だ。

　個人レベルでも、新しいPCを購入した場合などに、以前と同じ利用環境を再度作り上げる作業を行った経験がある人は多いだろう。たとえPC 1台であっても、元通りの環境を再現するには多大な手間がかかる。複数のサーバを組み合わせて利用していた場合などでは、その手間が膨大になることは容易に想像できるだろう。

　ユーザーデータと違って、ハードウェアやソフトウェアは失われたら最後、二度と復元できないというわけではない。しかし、復旧にかかる手間や時間が増大すると、それはシステム復旧がそれだけ遅れることを意味する。DRという観点からは、単に「復旧が可能か不可能」だけではなく「どのくらいの時間で復旧できるのか」も重要な問題となる。

　したがってバックアップとは逆に、障害発生時点を基準として、そこからどのくらいの時間でシステムの運用を再開できればよいのかをあらかじめ明確にしておく必要があるのだ。

　データ喪失が一切許されず、許容されるシステムダウンタイムもせいぜい数分程度というシステムでは、システムを完全に二重化し、バックアップサイトで主システムとほぼ同等の構成のシステムを用意しておくことになる。しかしながら、数日程度のダウンが許されるのであれば、バックアップサイトの用意までは必要ないだろう。これも結局、対策に要するコストと想定される被害額のバランスで決定することになる。

　もう1つ、ここで考えておかなくてはいけないのは、調達に要する時間だ。

　1台のPC程度であれば、量販店に出かけて店頭にあるものを何でもいいから買ってくるということもできるが、サーバとなるとそうはいかない。小規模なPCサーバであれば店頭に在庫があるかもしれないが、通常は早くても数日程度は待つことになる。

　これが大規模なUNIXサーバなどになると、発注してから納入されるまで数カ月程度の時間を要することもあり得る。ハイエンドクラスのサーバは、事実上受注生産であり、いくら復旧を急ぎたくてもどうにもならないという状況もあり得る。

想定範囲を拡げる努力を

　DRに関しては、「起こり得る災害」をどこまで想定するかが重要になる。

　通常の保護対策では、ハードウェアの故障やオペレーション・ミスによるデータ喪失などを想定して対策を講じることになる。しかし、さまざまな災害による被害の実例を振り返ると、現在では、より大規模な災害も「あり得ること」として想定の範囲に含めざるを得なくなっている。

　日本は世界有数の地震国でもあり、都市レベルで数日程度の機能麻痺が起こる可能性は低くはない。さらに、台風や大雨による水害の実例もある。大雪で交通網が寸断されて大きな被害や影響が生じたことも記憶に新しい。

　米国でも、同時多発テロに加え、ハリケーンによる被害でニューオーリンズが壊滅的な打撃を受けたという実例もある。こうした例を踏まえて、起こり得る被害を様々にシミュレーションし、必要な対策を検討していくことがDR実現のために極めて重要だ（関連記事）。

　大規模な自然災害を想定すれば、ITシステム以外にもさまざまな被害が発生する可能性がある。たとえば、システムの構成を熟知した熟練の運用管理担当者がサーバルームに駆けつけることができない、という事態も当然想定できる。これを想定すれば、手順を明確化してドキュメント化しておくことの意味もまた明らかだろう。

　また、交通網が寸断され、移動手段が確保できない可能性も考えられる。バックアップデータを遠隔地に保存している場合、すぐには運搬できないかもしれないのだ。あるいは、バックアップを保存したビルが、倒壊は免れたものの危険な状態になり、立ち入りが禁止されるという状況も考えられる。

　事実上、起こり得る全ての状況に対して万全に備える、ということは不可能である。しかし、それは対策は無意味だ、という意味ではない。