DR成功の切り札はテストの実施
どの企業も賠償責任保険に加入しておく必要があるように、どの企業もディザスター リカバリー（DR）計画を策定しておく必要があります。DR計画なしでは、災害から復旧できる可能性は、あるとしても、ごくわずかとなってしまうでしょう。もっとも、DR計画を策定してあればそれで十分というわけでもありません。実際に機能するかどうかを評価するためにDR計画のテストを実施しておく必要があります。
ソフトウェアが、本社でハウジングされているサーバーで稼働しているか、国全体をまたいだパブリック クラウドの巨大なラックの中で稼働しているかに関わらず、DR計画のテストは円滑な運用のためにはきわめて重要な要素です。こうした情報技術はおおかた信頼できるものです（IBM i を稼働している場合はほぼ必ず信頼できます）が、業務アプリケーションが利用できなくなるという場合もあります。
ITの正常な機能が停止するこうした状況では、企業はバックアップ計画を用意しておく必要があります。それは、壊滅的なサーバー障害（IBM i 環境ではほとんど耳にしませんが）であるかもしれませんし、システム設定の誤構成（これはよく起こりがちです）であるかもしれません。また、ネットワークもダウンします。これは、Uberとつながった世界では危険な事態です。
パブリック クラウドでの稼働には、それ特有のリスクを伴います。年間約460億ドルを生み出す世界最大のクラウド、 Amazon Web Servicesでは、先週、6時間にわたる障害が発生し、インターネットの大きな部分がダウンすることとなりました。原因は、伝えられるところによると、同社のKinesisデータ メッセージング サービスに容量を追加しようとしたことだったようです（やれやれ）。
よくあるもうひとつのIT障害の原因は、母なる自然によってもたらされる災害です。北アメリカは豊富な天然資源や見事な自然景観に恵まれていますが、その気候はと言うと、なかなか過激なようです。 気象学者によれば、広さが米国と同じくらいで、同じくらい多くの異常気象事象が発生する土地というのは、他に見つけるのは難しいというのが実際のところだそうです。
データを適切にバックアップしておき、それらにアクセスできるようにしておくことが極めて重要になります。ダウンタイムをどの程度許容できるかに応じて、それぞれ適切なセットアップが考えられます。通常のテープ バックアップ（BRMS、Robot/SAVE、またはIBM i の保管コマンドを使用）を実行することは、災害後にIBM i のショップが確実にデータを回復できるようにするための方法として、頼りになる方法であることに変わりありません。しかし、IBM i では、ディスクベースのバックアップおよび仮想テープ ライブラリーが、より広く使用されるようになりつつあります。また、これらのオプションには、クラウドベースのストレージを提供しているものもあります。
ダウンタイムの発生が望ましくない企業にとっては、大陸の反対側に位置する別のサーバーへ同期または非同期方式でデータを移動できるリアルタイム データ レプリケーション ソリューションが適切かもしれません。 Precisely 社（旧Vision Solutions社）のMIMIXおよびiTera HAオファリングから、 IBMのPowerHAオファリングまで、数多くのハイ アベイラビリティー製品が販売されています。
ダウンタイムを極力なくしたいIBM i のショップであれば、Db2 Mirrorオファリングを使用するのがよいでしょう。Db2 Mirrorでは、構内設定で同一のIBM i サーバーに2つのDb2 for iデータベースを接続することが可能です。このような継続的な可用性セットアップによって、計画的および計画外ダウンタイムはほとんどなくすことができますが、災害からの保護は提供されません。Db2 Mirrorは、構内設定での稼働に制限されているためです（IBMでは現在Db2 Mirrorの制限距離の延長を検討していますが）。
どのDRアプローチを選ぶにしても、IBM i のショップは、きちんと機能することを確認するために、リカバリーの訓練を実施しておく必要があります。残念ながら、DR計画の訓練を実施する時間を取れていないIBM i のショップが多過ぎるようです。今日の先進的なITショップに対する時間的および資源的制約を考えれば、無理もないことなのかもしれませんが、やはりそれでは目先のことにとらわれ過ぎと言わざるを得ません。
メリーランド州を拠点とするフルサービスDRプロバイダー、 Recovery Point Systems社（Sungard ASやIBM Business Continuity and Recovery Services（BCRS）と競合しています）と契約しているIBM i 顧客は、年に複数回、リカバリー計画の訓練を実施するようベンダーから積極的に勧められるようです。
「私たちはある種のPITA（面倒くさいこと）を扱うベンダーです」と、Recovery Point社のCOOであるRobert Hicks氏は述べます。「私たちはしきりにこう呼び掛けています。「DR計画のテストの予定を立てましょうか」と。こちらはいつでも準備ができています。」
DR計画は、策定時点ではうまくいきそうに思えるものですが、街の大規模火災や、ハリケーンによってフロリダ南部が半分吹き飛ばされてしまったときなど、そうした計画が機能しないケースも無数に考えられます。
サーバー構成は変更され、ライブラリーは追加・削除され、ユーザー プロファイルはあちこち移動されます。こうした変更をきちんと管理するためのプロセスを導入することはできますが、実際的なテストなしでは、実際に機能するのかどうか、本当に分かる術はありません。
「私たちは、DR計画がきちんと機能することをご確認いただける機会をご用意したいと思っています」とHicks氏は述べます。「それは、お支払いいただいただけの価値があることの証明となる、私たちが考え得る究極の方法だからです。」
