災害復旧とは何か?
災害復旧 (DR: ディザスタリカバリ) とは、火災、洪水、システム障害、人為的なミス、ランサムウェア攻撃といった破壊的な出来事が発生した後に、アプリケーションやデータへのアクセスとITインフラストラクチャの機能を回復するプロセスのことです。その目標は、災害の中でも業務を継続しし、システムを早急に正常な状態に戻すことにあります。災害復旧は、BCDRと呼ばれる事業継続と密接に関連しています。多くの場合この2つの用語はしばしば同じ意味で使われていますが、大きな違いがあります。災害復旧では技術システムを可能な限り迅速に回復させるのに対し、事業継続では組織全体の運用を維持することに重点を置いています。そのため、災害復旧は事業継続戦略の重要な一部となります。
なぜ災害復旧が重要なのか?
データと、その作成、保存、処理、分析を行うデジタル技術は事業運営に不可欠です。災害に襲われると、運用上の障害やミッションクリティカルなITシステムの使用不能によって事業と評判に深刻な影響が及ぶ可能性があります。 企業はデータへのアクセスを確保し、システムとインフラストラクチャの機能を早急に回復しなければなりません。ここでDRが役立ちます。
堅牢な災害復旧戦略は、以下の点で組織を支援するため重要です:
-
- ダウンタイムの最小化: システムやネットワークはさまざまな理由で停止する可能性があります。災害復旧計画を活用してこうした出来事を予測して備えることで、先手を打って被害を回避することができます。例えば、ミッションクリティカルなアプリケーションを実行するために、パブリッククラウドなどのセカンダリサイトを持つことは、災害に備えるひとつの方法です。
- データ損失の最小化: 企業は、災害復旧用のサイトや技術を利用してデータの損失を防止しています。多くの場合、データはセカンダリサイトに瞬時に複製されるので、データの損失はほぼ発生しません。さらに、優れたDRソリューションには、どの時点、どの場所からも重要なアプリケーションやデータをリストアできる柔軟性があります。これによって、事業継続体制を強化することができます。
- 全体の損害を軽減: ダウンタイムのコストは企業の他のセグメントにも必ず影響するものです。顧客満足度への悪影響、ブランドの評判の急速な低下、競合他社による攻撃などが起こる可能性があります。堅牢な災害復旧ソリューションがあれば、ITの域を越えたこうしたコストを回避することができます。これには、収益の損失、従業員の生産性や士気の低下も含まれます。
災害復旧の仕組みとは?
災害からの復旧には手動プロセスと自動プロセスがありますが、これは業務オペレーションによって異なります。一般的にデジタルDRでは、ミッションクリティカルな業務アプリケーションやデータベースなどのITシステムを可能な限り迅速に起動、実行してダウンタイムを短縮し、データの損失を防ぎます。
ほとんどの組織は、誰が、何を、どのように、IT復旧を行うべきかをまとめた正式なアクションプランを作成しています。計画した時間目標内にリソースを回復させて復旧を完了するための順序は、ランブックに詳述されるのが一般的です。
組織には、複製してセカンダリサイトにミラーリングしたアプリケーションやデータをリストアするという選択肢があります。例えば、代替サイトに企業が所有するサーバーがあり、災害発生時のフェイルオーバーオプションとしてミラーリングしたアプリケーションやデータが待機している場合があります。また、クラウドプロバイダーが提供するDR as a Service機能を選ぶこともできます。
いずれにせよ、自動災害復旧は、ポイントインタイムスナップショット、レプリケーション、自動フェイルオーバーとフェイルバックのオーケストレーションに集約されます。
災害復旧計画とは?
災害復旧計画はDRランブックと呼ばれることもあり、あらゆる事業継続計画のコアとなるものです。災害復旧計画を作成したら、テストと修正を定期的に行ってその運用性を継続的に確保できるようにする必要があります。
通常、災害復旧計画には、個々の重要度に基づいて重要なアプリケーションとデータの復旧優先順位を決めるための2つの重要な指標が盛り込まれます。これは通常、分、時間、日、週で測定されるものです:
- RTO (目標復旧時間): 災害発生から生産性を回復するまでにかかる時間をIT部門が予測したものです。
- RPO (目標復旧時点): 停止またはデータ損失が発生してから、バックアップ、スナップショット、データ同期までの間の最大許容時間。
最も効果的なDR計画は、システムの依存関係に対処し、ダウンタイムを最小限に抑えるためにはどのシステムをどのような順序で復旧するのか、その責任者とプロセスを詳細に記したものになります。DRランブックとプロセスをオーケストレーションする自動DRソリューションを使用しているチームは、インシデント発生時に迅速な対応とフェイルオーバーを行うことができます。
Disaster Recovery as a Serviceとは?
セルフマネージドのDRと同様に、Disaster Recovery as a Service (略してDRaaS) もデータの復旧とアプリケーションの可用性に関するSLA (サービスレベルアグリーメント) を自動で制御できる方法を提供するものですが、セカンダリサイトのデプロイや運用を自身で行うことに伴うコストや複雑性はありません。このソリューションによって、組織はクラウドの利点を活用しながら、迅速に復旧する能力を得ることができます。
DRaaSを活用すると、組織は必要なときだけ従量課金制のクラウドインフラストラクチャをオンデマンドでスピンアップさせることが可能です。そのため、ほとんどアイドル状態で、コストが高く管理も困難なセカンダリデータセンターは不要になります。チームは、災害復旧サービスを使用して、さまざまなアプリケーションの多数のSLA (サービスレベルアグリーメント) に対し、ほぼゼロのダウンタイムと最小限のデータ損失を実現することができます。
災害復旧計画を作成するには?
災害復旧計画 (DRランブック) を作成するには、まず、ITに関わる人員、プロセス、技術をすべて評価する必要があります。これらの情報を把握せずに、ハリケーン、洪水、ランサムウェア攻撃、人為的なミスなどの想定外の事態に遭遇すると、バックアップを確保し迅速に復旧することは不可能です。DR計画は、さらなるオペレーションを回復するための大規模な事業継続計画の一部である場合もあれば、そうでない場合もあります。DR計画は通常、ITシステムをダウンタイムからできる限り早急にリストアすることに焦点を当てたものです。
DR計画には以下の点を含める必要があります:
- 危機対応を管理するリーダーおよびITチーム: これは、DR計画を作成したチームと同じでも、同じでなくてもかまいません。
- ITソフトウェアやシステムの復旧を自動化する高度なソフトウェア
- ブループリントとスクリプト、およびエンタープライズITシステムのデータとITガバナンスプロトコル
- サポート/支援リソース
- システムを確実かつ適切に復旧するための安全なプロトコル
- 何が、いつオンラインに復旧するかに関する社内コミュニケーションチャネル
どのように災害復旧を設定するのか?
役員から現場まで、すべての従業員は組織のデータを保護するための何らかの責任を有しています。CIOおよびその他のITリーダーは通常、経営幹部やチームと連携して災害復旧の計画や技術を主導し、保護する必要のあるデータ、アプリケーション、ITインフラストラクチャの優先順位を付けます。このプロセスで重要なのは、ミッションクリティカルなリソース (事業運営に絶対に必要) と、ビジネスクリティカルなリソース (保持することは重要だが収益や安全性を阻害することのない) を定義することです。また、このプロセスにおけるもうひとつの重要な要素は、ビジネス全体の中で他の人が特定の機能に対して持っているSLAを決定することです。こうすることでITチームは、データ、アプリ、インフラストラクチャの復旧において、彼らがオンサイトでの復旧の責任を持つのか、サービスプロバイダーやクラウドプロバイダーとチームを組むのかを見極められるようになります。例えば、オンプレミスを選択するのか、あるいは、AWS、Microsoft Azure、Google Cloudが提供するDRaaSなどのクラウドオプションを選択するのか、ということを判断できるのです。現在、AWSでの災害復旧、AzureでのDR、Google CloudでのDRは人気が高まっています。
戦略的な保護を決定したら、災害復旧の計画とサービスの設定を目指して運用のリストア方法をさらに詳しく議論できるようになります。ここでDRランブックの登場です。なぜなら、DRランブックには、復旧に必要な人員、プロセス、技術的要件に関する情報が盛り込まれるからです。しかし、DRランブックは保管したままにせず、定期的にテストして適切な状態を保たなければなりません。この点において、DR機能のメンテナンスやテストがしやすいことは重要な検討事項になるでしょう。
災害復旧計画のテストでは、ランブックに記載された多数のステップをそれぞれ実行し、組織の災害復旧計画に漏れや誤りがないことを確認します。DR計画のテストは、万が一最悪の事態が発生した場合にも、ITシステムが可能な限り最もタイムリーかつ効率的にリストアできることを保証するものです。
ひとつのソリューションでバックアップを統合しDRを自動化できるDRソリューションは、ばらばらのポイントソリューションで発生する複雑さとコストを削減し、ダウンタイムとデータ損失をほぼゼロにしてオンプレミスとクラウドの両方のワークロードに対応できるため、場合によっては非常に魅力的な選択肢となります。
災害復旧にかかるコストとは?
あらゆるITイニシアティブ同様、災害復旧のサービスやソリューションにかかるコストはさまざまです。物理的または仮想的にデータを隔離する計画によっては、復旧のコストに、プライマリロケーションから何百マイルも離れたオフサイトロケーションから情報を物理的に取得するコストも含まれる場合があります。データの規模や保存場所の不安定な天候によっては、セカンダリサイトを複数設置する組織もあります。この場合、本番データの正確なコピーを複製し保存するためにコストのかかるハードウェアやソフトウェアのインスタンスを複数インストールし、万が一に備えて24時間体制で稼働させる場合もあります。クラウドコンピューティングや次世代データ管理といった近年の技術進展により、DRにかかるコストは大幅に低下しています。これは組織にとっては朗報です。なぜなら、その深刻度にもよりますが、ダウンタイムは組織にとって致命的なものとなりかねないからです。
サイバー攻撃などの災害にかかる財務コストは既に数10億ドルに達しており、今後10年間で2,560億ドルまで上昇することが予測されています。しかし、これらのコストに、収益、顧客ロイヤリティ、顧客満足度、従業員の生産性における潜在的損失は含まれていません。災害は必ず起きるものであり、災害復旧ソリューションを持たない準備不足の企業の方が、はるかにコストが掛かります。
災害復旧テストとは?
災害復旧テストは、ITチームが事業復旧SLAを満たすことができるという確信を得るためのものです。このテストは、社内外のコンプライアンス要件を満たしているかを確認する上でも役立ちます。サイバー攻撃の増加に伴い、DRテストの実績がサイバー保険の資格を得るための必須条件になる日も近いかもしれません。
災害復旧計画をテストするには?
災害復旧の計画やサービスのテストは、自動または手動で行えます。しかし、包括的なテストを行う場合は、人員、プロセス、技術という必要不可欠な要素を用意する必要があります。
テストを実施するチームは、復旧に責任を持つ役割、復旧の概要を説明する文書、RTO (目標復旧時間) とRPO (目標復旧時点) のコミットなどを完全にレビューしなければなりません。
プロセスの面では、アラート、手順、ハードウェア、ソフトウェア、ネットワーク、データ保護、バックアップと復旧のスナップショット、ランサムウェアからの復旧、ロールバックなどの観点から、何が発生し何が必要かを確認することもテスト対象になります。
テストは少なくとも4半期に1回、最高クラスの組織においては毎月行う必要があります。
一般的な災害復旧計画の5大要素とは?
災害復旧に関する以下の5つの要素に既に対応していれば、想定外の事態が発生した場合でも迅速な復旧できるよう準備することができます:
- 対応チームの特定: DR対応計画の策定と実行に向けて適切なチームとスタッフの役割を割り当てます。
- SLAの定義とリスクの評価: DR計画の予備計画や作成の一環として期待される復旧目標を文書化し、広範な可能性 (システム内のランサムウェアの動きなど) から復旧に関連するリスクを評価します。
- 運用に影響する重要システムの文書化: 短期的、中期的、長期的な復旧期間において災害や脅威を切り抜ける上で必要なシステムを、誰もが理解できるようにします。
- バックアップおよびデータ管理ソリューションのデプロイ (オプション): 次世代データ管理ソリューションを活用すれば、DRを個別に導入することも、バックアップと統合し、最適な効率、コスト削減、煩雑さの解消を実現することも可能です。Cohesityのような柔軟で包括的なマルチクラウド対応のデータ管理プラットフォームを評価、選択すれば、ビジネスクリティカルなアプリケーション、サービスレベル、環境全体でダウンタイムやデータ損失をほぼゼロにし、バックアップ、継続的データ保護、DRのフェイルオーバーとフェイルバックのオーケストレーションを自動化することが可能です。
- DRランブックを4半期に1回以上テストして継続的に更新: 運用は変化し、データが飛躍的に増加する中、災害復旧計画やDRサービスが常に稼働していることを確認し、即座かつ完璧に実行できるようにします。
災害復旧に最適な方法とは?
災害復旧を実施する方法は複数ありますが、広範なSLAと復旧時間に対応しつつ、ダウンタイムを最小限に抑えてシステムと運用における全体的な複雑性を抑制し、セカンダリインフラストラクチャの重複やアイドル状態をなくすことでコストを削減できるようなソリューションを探すことをおすすめします。また、DRデプロイメントを自社で管理するのか、クラウドやDRaaSモデルで管理してもらうのかを選べるような柔軟性があるものを探すと良いかもしれません。
災害復旧の種類とは?
組織は通常、自社のニーズに合わせて災害復旧サイトを設計します。最も一般的な選択肢は以下のとおりです:
- データセンターからセカンダリデータセンターへの災害復旧 (サイトツーサイト)
- データセンターからクラウドへの災害復旧 (サイトツークラウド)
- Disaster Recovery as a Service (DRaaS)
災害復旧チームを構築するには?
災害復旧チームは一般的に事業継続チームのサブセットになります。災害復旧チームの役割には、CIO、ITレジリエンス、危機対応、セキュリティ対応などの役割が含まれます。
DR計画の主な目標は、アプリケーション、データ、インフラストラクチャを迅速かつ完璧にリカバリさせることであるため、DRを担当するチームメンバーは一般的に、データセンター (コンピュート、ストレージ、ネットワーク、クラウド) を担当する技術専門家になります。
災害復旧ソフトウェアのメリットとは?
最も信頼できる災害復旧やDisaster Recovery as a Service (DRaaS) を利用することで、組織は次のことを実現することができます:
- 古いサイロ化したポイント製品を、オンプレミスやクラウドにあるアプリケーションやデータを保護する統合ソリューションに置き換えることで、DR運用のシンプル化
- オンプレミスやクラウドで、サイトからサイトへとレプリケーションを実施することでサイトを障害から保護
- ハイブリッドクラウド環境のバックアップとレプリケーションにポリシーベースの自動化を用いることで、レプリケーションの自動化と時間短縮
- 無停止のDRテスト、監査証跡、レポート対応
災害復旧とCohesity
災害復旧は複雑で高価なものです。何百ものアプリケーションを実行している企業は、これらのアプリケーションを重要度で階層化して個別のポリシーを定義し、各階層で複数のベンダーと連携してすべてをまったく異なるコンソールで管理しなければなりません。そこでCohesityは、災害からほぼ瞬時に復旧するだけではなく、導入されたアプリケーションの階層もすべてほぼ瞬時に復旧できるソリューションを提供しています。複雑で高価な、断片化したソリューションは、統合され自動化したDRフェイルオーバーとフェイルバックのオーケストレーションソリューションの登場によって過去のものとなりました。
Cohesityの信頼できる災害復旧および事業継続ソリューションは、以下のことを実現します:
- DR運用のシンプル化: Cohesityは、オンプレミスとクラウドの両方で、 階層、サービスレベル、環境に関係なく、アプリケーションとデータを保護する単一のソリューションで、組織のサイロ化したレガシーのDRポイント製品の時間のかかる管理を、統一されたポリシーフレームワークに置き換えます。
- サイトの障害に対する保護: Cohesityの災害復旧ソリューションでは、オンプレミスやクラウドでサイトからサイトへとレプリケーションを行い、サイト障害から保護することができます。
- レプリケーションの自動化: Cohesityが提供するポリシーベースの自動化を使用して、ハイブリッドクラウド環境におけるバックアップとレプリケーションが行えます。
- データ再利用の実現: Cohesity DRソリューションでは、開発/テストや分析といった他の目的のためにデータを代替ロケーションへと簡単に複製することができます。
- 無停止のDRテストに対応: Cohesityのソリューションが提供する無停止のDRテスト、監査証跡、レポートを活用すれば、運用上の複雑さを抑えてコンプライアンス要件を合理化することができます。
