災害復旧：概要

災害復旧とは

災害復旧（DR）は、ITテクノロジーと、破壊的な事象によって生じるデータ損失やビジネスの中断を予防または最低限に抑えるベスト・プラクティスで構成されています。これには、機器の故障や局所的な停電から、サイバー攻撃、非常事態、犯罪攻撃、軍事攻撃、自然災害まですべてが含まれます。

多くの企業、特に中小企業は、信頼性ある実用的な災害復旧計画を立てていません。こういった企業には、このような計画なしに著しい混乱をもたらすような事象による影響から保護する術はほとんどありません。

インフラストラクチャー障害のコストは 1時間当たり10万米ドル（IBM外部へのリンク）に及ぶことがあり、重大なアプリケーション障害のコストは1時間当たり50万から100万米ドルに及びます。多くの企業は、そのような損失から復旧できません。小規模企業の40％以上は災害経験後に再開することはなく、再開するところでも、さらに25％は危機発生後1年以内に倒産しています。災害復旧計画は、こういったリスクを劇的に低下させることができます。

災害復旧計画には、戦略化、計画、適切なテクノロジーの展開や継続的なテストが含まれます。データのバックアップの維持は災害復旧計画の重要な構成要素ですが、バックアップと復旧プロセスだけでは完全な災害復旧計画とはなりません。

災害復旧には、堅牢なフェイルオーバーおよびフェイルバック手順を維持するために適切なストレージとコンピューティングが利用できることを保証することも必要です。 フェイルオーバー は、生産プロセスやエンドユーザー体験ができるだけ中断しないよう、ワークロードをオフロードしてシステムをバックアップするプロセスです。 フェイルバック では、切り替えて元の1次システムに戻します。

バックアップおよび災害復旧計画の重要な区別の詳細については、こちらの記事をお読みください。

事業継続計画

事業継続計画では、危機や緊急事態時に、お客様の企業のあらゆる分野が重要な運営を維持し、できるだけ迅速に再開できるようにするためのシステムやプロセスを作成します。災害復旧計画は、ITインフラストラクチャーやシステムの復旧に焦点を当てた事業継続計画のサブセットです。

災害復旧計画

ビジネス・インパクト分析

包括的な災害復旧計画の作成は、ビジネス・インパクト分析から始まります。この分析を実行すると、一連の詳細にわたる災害シナリオが作成され、今度はそれを利用して特定のビジネス・プロセスが中断した場合の損失の規模や範囲を予測します。例えば、火災によってカスタマー・サービス・コール・センターが崩壊してしまった場合や、地震が本部を襲った場合などです。

これによってビジネスで最も重要な分野や機能が特定でき、こういった重要な機能それぞれがどの程度のダウンタイムに耐えられるのかを判断することができます。このような情報を手に、お客様はさまざまなシナリオで最も重要な業務をどのように維持できるのかの計画を立て始めることができます。

IT災害復旧計画は、事業継続計画に従い、またそれを支援するようなものであるべきです。事業継続計画によって、コール・センターの火災後にお客様サービス担当者が自宅から勤務する必要があるのであれば、その計画を支援するためには、どのような種類のハードウェア、ソフトウェア、そしてITリソースが必要でしょうか。

リスク分析

ビジネスが直面するリスクの可能性とそれによって考えられる結果を評価するのも、災害復旧計画の重要な構成要素です。サイバー攻撃やランサムウェアはかなりまん延してきており、今日あらゆる企業が直面する一般的なサイバーセキュリティー・リスク、またお客様の業界や地理的な位置に特有のリスクを理解することは非常に重要です。

自然災害、機器の故障、インサイダー脅威、妨害行為、従業員のエラーと言ったさまざまなシナリオに対してリスクを評価し、ビジネスへの全体的な影響を考慮する必要があります。次の質問を自問してください。

販売機会を逃したり、収益を生み出す活動が中断されることによって、どのような金銭的損失を被るでしょうか。
お客様のブランドの評判には、どういったダメージがあるでしょうか。また、顧客満足度にはどう影響するでしょうか。
従業員の生産性にはどう影響するでしょうか。何時間の労働時間が失われるでしょうか。
それによって、人の健康や安全にどのようなリスクが課されるでしょうか。
ビジネス・イニシアチブや目標に対する進捗状況に影響するでしょうか。どのように影響するでしょうか。

アプリケーションの優先順位付け

すべてのワークロードがビジネスの業務を維持する能力に同等に重要であるわけではなく、また一部のアプリケーションでは他のアプリケーションよりもダウンタイムの許容度がかなり高くなっています。どのくらいの間ダウンしていても耐えられるか、またデータ損失がどの程度重大な結果をもたらすかによって、システムとアプリケーションを3つの層に分けます。

ミッション・クリティカル： その機能がビジネスの存続に不可欠であるアプリケーション。
重要： 比較的短期間のダウンタイムに耐えられるアプリケーション。
必須ではない： 一時的に手動プロセスに置き換えたり、またはそれなしで済ますことができるアプリケーション。

依存関係の文書化

災害復旧計画の次のステップは、ハードウェアおよびソフトウェア資産の完全な目録の作成です。この段階で、重要なアプリケーションの相互依存性を理解することは非常に重要です。あるソフトウェア・アプリケーションがダウンした場合、影響を受けるのは他のどのソフトウェアでしょうか。

レジリエンシー、そして災害復旧モデルを、当初構築されたとおりにシステムに組み込んで設計するのが、アプリケーションの相互依存性を管理する最良の方法です。今日のマイクロサービス・ベースのアーキテクチャーでは、他のシステムやプロセスがダウンしているときには開始できないプロセスがあり、またその逆もよくあります。この状況から復旧するのは難しく、実際に災害が起こる前に、システムやプロセスに対して代替計画を展開する時間があるときにそのような問題を見い出すことが不可欠です。

目標復旧時間、目標復旧ポイント、そして目標復旧一貫性の確立

リスクとビジネス・インパクト分析を考慮することにより、システムを回復させるまでにどのくらいの時間が必要か、どの程度のデータの使用に耐えられるか、またどの程度のデータ破損またはデータ逸脱に耐えられるかの目標を確立できます。

目標復旧時間（RTO）は、サービスの中断後に機能するアプリケーションまたはシステムを復元するのに必要な最大時間です。

目標復旧ポイント（RPO）は、ビジネスが通常運営を再開するために復旧しなければならないデータの最高寿命です。一部の企業ではたった数分に相当するデータを失うだけでも壊滅的であることもある一方で、他の業界の企業は、より長いウィンドウに耐えられることがあります。

目標復旧一貫性（RCO）は、連続したデータ保護サービスに対してサービス・レベル・アグリーメント（SLA）で確立されます。これは、災害復旧状態において、復旧したプロセスやシステムからのビジネス・データのうち、いくつまでの一貫していない入力が許容されるかを示す測定基準であり、複雑なアプリケーション環境全体でのビジネス・データの完全性を説明します。

規制遵守問題

企業が確立したすべての災害復旧ソフトウェアおよびソリューションは、遵守する義務のあるあらゆるデータ保護およびセキュリティー要件を満たす必要があります。これは、すべてのデータ・バックアップおよびフェイルオーバー・システムを、1次システムのデータの機密性および完全性を確保するための基準と同様の基準を満たすように設計する必要があることを意味します。

同時に、複数の規制基準は、すべてのビジネスが災害復旧計画や事業継続計画を維持する必要があると規定しています。例えばサーベンス・オクスリー法（SOX）は、米国内のすべての公開会社にあらゆるビジネス記録のコピーを5年以上保持するように要求しています。この規制に従わない場合（適切なデータ・バックアップ・システムの確立やテストを怠る場合を含む）には、企業に多大な罰金が科されたり、首脳陣に懲役が科されることもあります。

テクノロジーの選択

バックアップは、強固な災害復旧計画を構築する基盤にもなります。過去には、大半の企業がバックアップを磁気テープや回転ディスク（HDD）に頼っており、少なくとも施設外1か所以上でデータのコピーを複数保持し、保管していました。

今日の常時接続のデジタルに変換する世界では、施設外のレポジトリーでの磁気テープによるバックアップでは、ビジネスに不可欠な業務を維持するために必要なRTOを達成できないことがよくあります。独自の災害復旧ソリューションを設計するには、実稼働環境の多数の機能を複製する必要があり、サポート・スタッフ、運営、施設、インフラストラクチャーのコストが発生します。このため、多くの組織はクラウド・ベースのバックアップ・ソリューションやフルスケールのサービスとしての災害復旧（DRaaS）プロバイダーに目を向けています。

復旧サイトの選択

独自の災害復旧データセンターを構築するには、複数の競合する目的のバランスを取る必要があります。一方では、主要サイトと同じ地震や環境上の脅威、その他の危険に影響されることのないよう、データのコピーを本部やオフィスのある場所から地理的に十分に遠いところに保管する必要があります。他方では、施設外に保管されたバックアップは1次サイトのオンプレミスにあるものよりも常に復元に時間がかかり、距離が長くなるとネットワーク待ち時間も長くなる可能性があります。

継続的なテストおよび確認

簡単に言えば、テストされていなければその災害復旧計画を信頼することはできません。重要な責任を持つ従業員は全員、災害復旧テストの演習に参加するべきです。演習には、ある期間のフェイルオーバー・サイトからの業務の維持などが含まれます。

包括的な災害復旧テストの実施が予算外またはその能力を超える場合には、テスト手順の「机上演習」ウォークスルーをスケジュールすることもできますが、この種のテストは、フルテストに比べてDR手順の異常や弱点を明らかにする可能性は低いことを覚えておく必要があります。特に以前に検出されていないアプリケーション相互依存性がある場合はそうです。

ハードウェアおよびソフトウェア資産は時間と共に変化しますので、災害復旧計画も確実に更新する必要があります。また、継続的かつ定期的に計画を見直し、改訂していくといいでしょう。

IBM Knowledge Centerは、災害復旧計画の例を提供します。

サービスとしての災害復旧（DRaaS）

サービスとしての災害復旧（DRaaS）は、今日利用可能な、最も人気のある急成長中のマネージドITサービスの1つです。ベンダーは、ダウンタイム限界とアプリケーションの復旧見込みの概要を記述するサービス・レベル・アグリーメント（SLA）でRTOとRPOを文書化します。

DRaaSベンダーは、通常クラウド・ベースのフェイルオーバー環境を提供します。お客様のデータセンターにある冗長性に特化したハードウェア・リソースの維持と比較すると、このモデルではかなりコストが節約されます。フェイルオーバー機能の維持と、災害復旧状況で消費されるリソースの利用当たりのコストに対する料金を支払う契約が利用可能です。ベンダ―は、通常フェイルオーバー環境の設定と維持に全責任を負います。

災害復旧サービスで提供されるサービスは、ベンダーによって異なります。サービスを包括的でオールインワンのソリューションとして定義するベンダーもあれば、単一のアプリケーションの復元からデータセンターのクラウドでの完全複製に至るまで、個別サービスを提供するベンダーもあります。また、災害復旧計画やテストサービスが含まれていることもありますが、このようなサービスには追加コンサルティング費用がかかるところもあります。

提携しているあらゆるパブリッククラウド・プロバイダー同様、依存しているエンタープライズ・ソフトウェア・アプリケーションがすべてサポートされていることを確認しましょう。また、アプリケーション性能がフェイルオーバー環境で満足できるものであり、フェイルオーバーやフェイルバック手順が十分にテストされていることも確認します。

クラウドDR

既にオンプレミスの災害復旧（DR）ソリューションを構築している場合は、月額のDRaaSサブスクリプションに移行するのと比較して維持のコストとメリットを評価するのは難しいことがあります。

オンプレミスDRソリューションの大半では、ハードウェア、電力、維持や運営の人件費、ソフトウェア、ネットワーク接続のコストが発生します。 DR環境の初期設定に関与する先行投資の資本支出に加え、定期的なソフトウェアのアップグレードも予算に計上する必要があります。 DRソリューションは常に1次実稼働環境に対応していなければならないため、DRソリューションが同じソフトウェア・バージョンであることを確認する必要があります。ライセンス契約の詳細により、これによってソフトウェア・コストが実質的に倍になることもあります。

DRaaSサブスクリプションへの移行によってハードウェアおよびソフトウェア支出が削減されるだけでなく、フェイルオーバー・サイトの維持の負担をベンダーに移すことで人件費も削減できます。

サード・パーティー製DRaaSソリューションを検討している場合は、ベンダーにクロス・リージョナルのマルチサイト・バックアップ能力があるかどうかを確認する必要があります。ハリケーンのような重大な気象事象によってメイン・オフィスのあるところが被害を受けた場合、フェイルオーバー・サイトは嵐に影響されないくらい離れたところにあるでしょうか。また、ベンダーには、そのエリアのお客様の多くが同時に影響を受けた場合に、全員のニーズを満たせる適切な能力があるでしょうか。 DRaaSベンダーは危機時のRTOやRPOを満たすことができると信頼しているのですから、信頼性において確固たる評判のあるサービス・プロバイダーを探しましょう。

両ソリューションの包括的な概要については、「サービスとしての災害復旧（DRaaS）と災害復旧（DR）：どちらが必要か」をお読みください。