Cohesityは今年もリーダーの1社に! 「2023年Gartner®エンタプライズ・バックアップ／リカバリ・ソフトウェア・ソリューションのMagic Quadrant™」レポートを入手する
災害復旧 (DR: ディザスタリカバリ) とは、火災、洪水、システム障害、人為的なミス、ランサムウェア攻撃といった破壊的な出来事が発生した後に、アプリケーションやデータへのアクセスとITインフラストラクチャの機能を回復するプロセスのことです。その目標は、災害の中でも業務を継続しし、システムを早急に正常な状態に戻すことにあります。災害復旧は、BCDRと呼ばれる事業継続と密接に関連しています。多くの場合この2つの用語はしばしば同じ意味で使われていますが、大きな違いがあります。災害復旧では技術システムを可能な限り迅速に回復させるのに対し、事業継続では組織全体の運用を維持することに重点を置いています。そのため、災害復旧は事業継続戦略の重要な一部となります。
データと、その作成、保存、処理、分析を行うデジタル技術は事業運営に不可欠です。災害に襲われると、運用上の障害やミッションクリティカルなITシステムの使用不能によって事業と評判に深刻な影響が及ぶ可能性があります。 企業はデータへのアクセスを確保し、システムとインフラストラクチャの機能を早急に回復しなければなりません。ここでDRが役立ちます。
堅牢な災害復旧戦略は、以下の点で組織を支援するため重要です:
災害からの復旧には手動プロセスと自動プロセスがありますが、これは業務オペレーションによって異なります。一般的にデジタルDRでは、ミッションクリティカルな業務アプリケーションやデータベースなどのITシステムを可能な限り迅速に起動、実行してダウンタイムを短縮し、データの損失を防ぎます。
ほとんどの組織は、誰が、何を、どのように、IT復旧を行うべきかをまとめた正式なアクションプランを作成しています。計画した時間目標内にリソースを回復させて復旧を完了するための順序は、ランブックに詳述されるのが一般的です。
組織には、複製してセカンダリサイトにミラーリングしたアプリケーションやデータをリストアするという選択肢があります。例えば、代替サイトに企業が所有するサーバーがあり、災害発生時のフェイルオーバーオプションとしてミラーリングしたアプリケーションやデータが待機している場合があります。また、クラウドプロバイダーが提供するDR as a Service機能を選ぶこともできます。
いずれにせよ、自動災害復旧は、ポイントインタイムスナップショット、レプリケーション、自動フェイルオーバーとフェイルバックのオーケストレーションに集約されます。
災害復旧計画はDRランブックと呼ばれることもあり、あらゆる事業継続計画のコアとなるものです。災害復旧計画を作成したら、テストと修正を定期的に行ってその運用性を継続的に確保できるようにする必要があります。
通常、災害復旧計画には、個々の重要度に基づいて重要なアプリケーションとデータの復旧優先順位を決めるための2つの重要な指標が盛り込まれます。これは通常、分、時間、日、週で測定されるものです:
最も効果的なDR計画は、システムの依存関係に対処し、ダウンタイムを最小限に抑えるためにはどのシステムをどのような順序で復旧するのか、その責任者とプロセスを詳細に記したものになります。DRランブックとプロセスをオーケストレーションする自動DRソリューションを使用しているチームは、インシデント発生時に迅速な対応とフェイルオーバーを行うことができます。
セルフマネージドのDRと同様に、Disaster Recovery as a Service (略してDRaaS) もデータの復旧とアプリケーションの可用性に関するSLA (サービスレベルアグリーメント) を自動で制御できる方法を提供するものですが、セカンダリサイトのデプロイや運用を自身で行うことに伴うコストや複雑性はありません。このソリューションによって、組織はクラウドの利点を活用しながら、迅速に復旧する能力を得ることができます。
DRaaSを活用すると、組織は必要なときだけ従量課金制のクラウドインフラストラクチャをオンデマンドでスピンアップさせることが可能です。そのため、ほとんどアイドル状態で、コストが高く管理も困難なセカンダリデータセンターは不要になります。チームは、災害復旧サービスを使用して、さまざまなアプリケーションの多数のSLA (サービスレベルアグリーメント) に対し、ほぼゼロのダウンタイムと最小限のデータ損失を実現することができます。
災害復旧計画 (DRランブック) を作成するには、まず、ITに関わる人員、プロセス、技術をすべて評価する必要があります。これらの情報を把握せずに、ハリケーン、洪水、ランサムウェア攻撃、人為的なミスなどの想定外の事態に遭遇すると、バックアップを確保し迅速に復旧することは不可能です。DR計画は、さらなるオペレーションを回復するための大規模な事業継続計画の一部である場合もあれば、そうでない場合もあります。DR計画は通常、ITシステムをダウンタイムからできる限り早急にリストアすることに焦点を当てたものです。
DR計画には以下の点を含める必要があります:
役員から現場まで、すべての従業員は組織のデータを保護するための何らかの責任を有しています。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つの要素に既に対応していれば、想定外の事態が発生した場合でも迅速な復旧できるよう準備することができます:
災害復旧を実施する方法は複数ありますが、広範なSLAと復旧時間に対応しつつ、ダウンタイムを最小限に抑えてシステムと運用における全体的な複雑性を抑制し、セカンダリインフラストラクチャの重複やアイドル状態をなくすことでコストを削減できるようなソリューションを探すことをおすすめします。また、DRデプロイメントを自社で管理するのか、クラウドやDRaaSモデルで管理してもらうのかを選べるような柔軟性があるものを探すと良いかもしれません。
組織は通常、自社のニーズに合わせて災害復旧サイトを設計します。最も一般的な選択肢は以下のとおりです:
災害復旧チームは一般的に事業継続チームのサブセットになります。災害復旧チームの役割には、CIO、ITレジリエンス、危機対応、セキュリティ対応などの役割が含まれます。
DR計画の主な目標は、アプリケーション、データ、インフラストラクチャを迅速かつ完璧にリカバリさせることであるため、DRを担当するチームメンバーは一般的に、データセンター (コンピュート、ストレージ、ネットワーク、クラウド) を担当する技術専門家になります。
最も信頼できる災害復旧やDisaster Recovery as a Service (DRaaS) を利用することで、組織は次のことを実現することができます:
災害復旧は複雑で高価なものです。何百ものアプリケーションを実行している企業は、これらのアプリケーションを重要度で階層化して個別のポリシーを定義し、各階層で複数のベンダーと連携してすべてをまったく異なるコンソールで管理しなければなりません。そこでCohesityは、災害からほぼ瞬時に復旧するだけではなく、導入されたアプリケーションの階層もすべてほぼ瞬時に復旧できるソリューションを提供しています。複雑で高価な、断片化したソリューションは、統合され自動化したDRフェイルオーバーとフェイルバックのオーケストレーションソリューションの登場によって過去のものとなりました。
Cohesityの信頼できる災害復旧および事業継続ソリューションは、以下のことを実現します:
