ディザスタ・リカバリ

ディザスタ・リカバリ(災害対策)に関する用語や具体的な方法など

AI駆動型クラウド災害復旧の導入方法

これまで、データバックアップおよび災害復旧ベンダーのほとんどは、自社製品にAI機能を直接統合していません。技術購入者は、ツールに「AI」というラベルを安易に貼っているベンダーには警戒すべきです。なぜなら、ベンダーが「あらゆる自動化はAIの一形態である」と主張し、この用語を大雑把に用いているケースがあるからです。実際にはそうではありません。

競合他社を過度に批判していると非難されないよう、IDCの災害復旧におけるAIに関するレポートを引用しておこう。「災害復旧および事業継続ソリューションにおける包括的なAIの活用はまだ初期段階にある。ただし、厳密な定義には当てはまらない場合でも、ほとんどのベンダーが何らかの技術をAIとして位置付けている」と述べている。IDCはさらに、AI搭載機能が災害復旧ツールの主要要素となるのは少なくとも2025年以降と予測している。

つまり、クラウド災害復旧戦略にAIを統合するには、単に「AI対応」を謳うツールを購入して終わりでは不十分です。しかし企業ができるのは、汎用的なAI技術を災害復旧シナリオに応用することです。

そのための基本手順は以下の通りです。

#1. AI活用事例を特定する

まず、災害復旧の文脈でAIに何を期待するかを明確にする。過去の課題から復旧作業の精度と信頼性を高めることが目的か?予算制約からコスト削減を目指すか?それとも別の目的か?

AIソリューションに何を期待するかを把握することは、実現方法を決める上で重要。

#2. AIツールまたはプラットフォームの選択

次に、想定するユースケースをサポート可能なAIツールまたはプラットフォームを選択します。一般的に、OpenAIのGPTモデルやGoogle Geminiなどのいわゆる生成AI基盤モデルは、復旧計画の分析やプレイブック生成など、AI駆動型災害復旧に関連するタスクを実行できます。これらのソリューションの利点は、事前学習済みで使いやすいことです。

とはいえ、ソフトウェア開発リソースと専門知識があれば、独自のAIモデルを構築したり、既存のオープンソースモデルをカスタマイズしたりすることも可能です(容易ではありませんが)。

#3. モデルに関連データを学習させる

使用するAIツールやプラットフォームを選んだら、ユースケースを理解するために必要なデータをモデルに学習させます。例えば、プレイブック生成が目的なら、ファイル・ディレクトリ・データベースのマッピングをモデルに提示し、復旧手順の提案を依頼できます。あるいは、バックアップデータ構造と本番システムのマッピングを投入し、復旧成功率を高めるバックアップ改善策を求められます。

機密性の高いビジネスデータをサードパーティのAIツールやプラットフォームに公開することは、プライバシーリスクを伴う可能性があることに留意してください。これを軽減するには、ユーザーデータの管理方法について厳格な保証と制御を提供するモデルを選択します。あるいは、可能であれば、ディレクトリ自体ではなくファイルディレクトリ構造などの情報を共有することで、機密情報の公開を完全に回避します。

#4. AI駆動ワークフローの訓練と更新

バックアップと復旧の要件は頻繁に変化する可能性が高いため、運用を支えるAI駆動ワークフローの更新も必要です。例えば、新しいアプリケーションやデータベースを導入した場合、変更を確実に反映させるために、更新されたプレイブックを生成したり、復旧戦略を再評価したりすることが望ましいでしょう。

バックアップとリカバリーに関するWasabiの活用方法

●冗長化のためWasabiと二次バックアップ場所を組み合わせる: 別のバックアップ先(オンプレミスまたは他クラウドプロバイダー)と組み合わせることで、予期せぬ障害発生時にも事業継続性を確保します。

●バージョン管理と併せてWasabiオブジェクトロックを活用する: 両者を組み合わせることで、部分的な破損や意図しない変更が発生した場合にファイルの状態を以前の状態にロールバックでき、ランサムウェアに対する強固な防御策となります。

●移行後のデータ検証と整合性チェックを実行:定期的な整合性チェック(チェックサム検証経由)を実行し、重要なバックアップファイルが完全かつ変更されていないことを確認します。これにより、時間の経過に伴うサイレントデータ破損を防ぎます。

●高速復元目標によるバックアップスケジュールの最適化:バックアップウィンドウを最小化するスケジュールを設計します。バックアップが時間依存性を持つ場合、オフピーク時間帯のWasabiの高速性を活用し、パフォーマンスを最大化します。

●バックアップテストと復旧シミュレーションの自動化:テスト実行を自動化し、バックアップデータが目標RTO(復旧時間目標)とRPO(復旧ポイント目標)内で復元可能であることを確認します。Wasabiはデータ転送量(エグレス)を課金しないため、定期的な訓練でも予期せぬコストが発生しません。

 Kubernetesバックアップに関するヒント

バックアップインフラを本番クラスターから分離: バックアップコントローラーとストレージ統合を、プライマリクラスターへの依存を最小限に抑えた独立した管理クラスターまたは分離されたネームスペースでホストします。

動的PVC検出とラベリングによるアプリケーション認識型バックアップ: バックアップジョブへの自動包含を実現します。作成時にボリュームにアプリケーション識別子をタグ付けすることで、粒度を向上させ、マルチテナント環境やネームスペースが密集した環境におけるボリュームの取りこぼしリスクを低減します。

ランサムウェア耐性のための不変・時間ロック型バックアップの実装: S3 Object Lockの組み込みサポートにより、N2WSはバックアップにWORM(Write Once Read Many)ポリシーを適用可能。これにより有効期限前の変更や削除を防止します。

シミュレート復元テストによるフェイルオーバー検証の自動化:インフラストラクチャ・アズ・コードのテンプレートとCI/CD自動化を活用し、バックアップから定期的に分離された「カナリアクラスター」を起動。復元が完全に行われ、ワークロードが期待通りに機能することを検証します。

ワークロードの重要度とライフサイクルに基づく保持ロジックの適用:ワークロードを重要度別に分類し、バックアップ頻度・有効期限・ストレージ階層を適切に調整。規制対応バックアップと一時的な開発ワークロードでは、異なるローテーションポリシーが必要となる場合があります。

Veeam KastenはKubernetes専用のデータ保護ソリューションで、各種Kubernetesディストリビューション上のステートレス/ステートフルなアプリケーションの構成と永続ボリューム上のデータ、OpenShift VirtualizationやSUSE Virtualization(Harvester)の仮想マシンに対してバックアップとリストア、モビリティを提供します。

Azureの停止を回避する方法

●ワークロードに応じたフェイルオーバー優先度の設定: すべてのワークロードが即時復旧を必要とするわけではありません。重要度に応じて分類し、階層化されたフェイルオーバー計画を設計します。ミッションクリティカルなシステムにはホットスタンバイ環境を有効化し、重要度の低いシステムにはコスト削減のためウォームまたはコールドリカバリを計画します。

●DNSフェイルオーバー自動化の事前準備: 停止はDNSレイヤーでアプリケーション可用性を損なうことが多い。Azureエンドポイント障害を自動検知し、最小限の遅延で代替リージョンやクラウドへトラフィックをリダイレクトするグローバルDNSフェイルオーバーソリューションを導入する。

●迅速な復旧のための不変インフラストラクチャの展開: インフラストラクチャ・アズ・コード(IaC)を活用し、環境定義をGitリポジトリに保存します。これにより、Azureのコントロールプレーン可用性に依存せず、他の地域やクラウドへの重要サービスの迅速かつクリーンなデプロイが可能になります。

●プロアクティブな対策のためのAzureサービスヘルスAPIの監視: これを監視スタックに統合し、サービス問題のプログラム通知を受信します。顧客に影響が出る前にワークロードを先制的にリダイレクトする自動スケーリングやフェイルオーバースクリプトと組み合わせます。

●分割シナリオに対する地域間レプリケーションの強化: 地域を跨ぐアクティブ-アクティブアーキテクチャを使用する場合、部分的な障害時の分割脳を防止するため、データ層に競合解決ロジックを設計します。重要なデータパスにはクォーラムベースの書き込みや強一貫性モデルを活用します。

Wasabiはバックアップと復旧にどのように活用されるのか?

●冗長化のためWasabiを二次バックアップ拠点と組み合わせる:別のバックアップ先(オンプレミスまたは他クラウドプロバイダー)と組み合わせることで、予期せぬ障害発生時にも事業継続性を確保します。

●バージョン管理と併せてWasabiオブジェクトロックを活用する:両者を組み合わせることで、部分的な破損や意図しない変更が発生した場合にファイルの状態を以前の状態にロールバックでき、ランサムウェアに対する強固な防御策となります。

●移行後のデータ検証と整合性チェックを実行:定期的な整合性チェック(チェックサム検証経由)を実行し、重要なバックアップファイルが完全かつ変更されていないことを確認します。これにより、時間の経過に伴うサイレントデータ破損を防ぎます。

●高速復元目標でバックアップスケジュールを最適化:バックアップウィンドウを最小化するスケジュールを設計します。バックアップが時間依存性を持つ場合、オフピーク時間帯のWasabiの高速性を活用し、パフォーマンスを最大化します。

●バックアップテストと復旧シミュレーションの自動化:テスト実行を自動化し、バックアップデータが目標RTO(復旧時間目標)とRPO(復旧ポイント目標)内で復元可能であることを確認します。Wasabiはデータ転送量(エグレス)を課金しないため、定期的な訓練でも予期せぬコストが発生しません。

ランサムウェアからの復旧に組織が要する平均期間は?

マルウェア侵害から1週間以内に復旧できる組織は35%のみであり、34%の組織は1か月以上を要します。
ランサムウェア攻撃時のデータ復旧手段として身代金支払いは有効か?否。身代金を支払った組織の46%のみがデータを正常に復旧でき、80%が再攻撃を受け再び危険に晒されました。

EUサイバーセキュリティ法とサイバーレジリエンス法の違いは?

サイバーセキュリティ法は、ITシステムのセキュリティを認証するための枠組みを提供します。サイバーレジリエンス法は、ハードウェアおよびソフトウェアの製造業者に対し、システムが設計段階で安全であることを保証するための必須セキュリティ要件を定めています。

サイバーレジリエンスとサイバーリカバリの違いは?

サイバーリカバリは、サイバーセキュリティと同様に、サイバーレジリエンスアプローチの一部です。サイバーリカバリーは、侵害発生時のバックアップや破損データの自動復旧などに焦点を当てます。一方、サイバーレジリエンスは、復旧を必要としないよう資産を保護することにも重点を置きます。

サイバーレジリエンスとサイバーセキュリティの主な違いは?

サイバーセキュリティは特定の脅威の防止と対応に焦点を当てます。サイバーレジリエンスは、セキュリティだけでなく、侵害発生時の復旧も含めた包括的なアプローチであり、企業を可能な限り早期に最適な運用状態に戻すことを目指します。

バックアップについての結論

これらの簡潔な回答により、バックアップ関連の用語を区別し、容易に採用できるバックアップのベストプラクティスを理解するのに役立ちます。バックアップ作業をさらに便利かつシンプルにするには、主要なクラウドストレージプロバイダーを活用し、すべてのバックアップ操作を一元管理し、堅牢なデータ保護を実現するために設計されたクライムのバックアップ・ソリューション群をお試しください。

3-2-1バックアップ戦略とは?

3-2-1バックアップ戦略は、バックアップコピーを異なる保存場所に分散させることで、潜在的なデータ損失の抜け穴を塞ごうとするものです。つまり、複数のバックアップ場所からシステムを復旧できるということです。

本質的には、データの3つのコピーを少なくとも持つべきです:2つは異なるデバイスにローカルでバックアップされ、1つはクラウドなどのオフサイトバックアップ場所に保存されます。

 

データバックアップのベストプラクティスとは?

最善の結果を得るためには、以下の手順を踏むべきです:

  • まず、システム内のデータの種類を定義することから始めます。ここで、ホットデータ、コールドデータ、アーカイブデータ、システムデータ、アプリケーション設定データ、運用データを特定します。
  • その定義が完了したら、各データクラスに最適なバックアップの種類を選択できます。
  • その際、理想的なバックアップ先も選択すべきです。ここでローカル、クラウド、ハイブリッドバックアップストレージの中から選択します。
  • その後、包括的なバックアップ計画を作成し、対応するバックアップスケジュールを策定できます。
  • 長期的な事業継続を確保するため、全体的な復旧時間目標(RTO)復旧時点目標(RPO)の算出と設定を検討してください。
  • 災害発生時のダウンタイムの実際のコストをさらに評価し理解することを忘れないでください。
  • そして最も重要なのは、標準的な3-2-1データバックアップ戦略に従うことです。

バックアップすべきデータとその頻度は?

実際のところ、システム内のあらゆるデータを例外なくバックアップすべきです。

ただし、その際にはデータの種類ごとに異なる扱いが必要であることを覚えておいてください。

例えば、バックアップの頻度自体がすべてのファイルで同じというわけではありません。データの「重要度」によって異なります。その点に関して、バックアップ対象データは主に3つの分類に分けられます:

 

  • ホットデータは最も重要です。日常的に復元が必要となる可能性のある本番データベースが含まれます。そのため、定期的にバックアップし、その後の変更はリアルタイムで更新されるべきです。
  • コールドデータは重要度が低く、データ損失後にのみ復元されます。つまり、バックアップデータの更新は週次程度で十分です。
  • アーカイブデータはコンプライアンスや監査目的のみに保存されます。通常は数年単位でバックアップされ、更新はごく稀に行われます。

別の見方としては:

 

  • オペレーティングシステムファイルは、初回にフルバックアップを実施し、その後はシステムファイルに変更が検出されるたびに(頻度は低いものの)フルバックアップで更新すべきです。
  • アプリケーション設定データも同様にフルバックアップを実施し、ソースマシンでアプリケーションデータが変更された場合にのみ更新すべきです。
  • 一方、運用ファイルは、絶えず変化するミッションクリティカルなデータを保持しているため、定期的にバックアップと更新を行う必要があります。

どの種類のバックアップを使用すべきか?

どの種類のバックアップを使用すべきか?

各状況に適したバックアップを選択する際、以下のポイントに留意してください:

  • 常にフルバックアップから始めるべきです。これは後続のバックアップの基盤となります。ただし、それだけで終わらせてはいけません。データの整合性とバックアップの信頼性を確保するため、他の種類のバックアップを実行している場合でも、定期的にフルバックアップを実行することが推奨されます。
  • 毎回フルバックアップを行う代わりに、増分バックアップをより頻繁に実行しつつ、フルバックアップは時折のみ実施することを検討してください。これは、データセット全体を再アップロードする負担なくフルバックアップを更新する便利な方法です。唯一の問題は、データ変更の一部を喪失するとバックアップ全体が損なわれる点です。
  • データ復旧能力の高速化を目指すなら、差分バックアップを優先することをお勧めします。特にMicrosoft SQLサーバーのバックアップと復元において効果的です。
  • システムレベルのバックアップを迅速化するには、合成フルバックアップの仕組みを構築すべきです。

VMバックアップとは?

VMバックアップは、仮想マシンからデータのコピーを転送し、バックアップストレージに保存することを目的としています。このアーキテクチャは、もちろんローカルマシンとは異なり、ブロック追跡をサポートするように設計されています。

アプリケーション対応バックアップとは?

アプリケーション対応バックアップは、特定のアプリケーションの完全な状態をバックアップすることを目的としています。特定の時点において、アプリケーションデータとその関連設定をコピーして保存します。これにより、アプリケーションを完全な状態で完全に復元することが容易になります。

イメージベースのバックアップとは?

イメージベースのバックアップとは、ソースマシンのハードドライブデータと関連するすべての設定をコピーし、バックアップストレージに保存する特殊な技術です。これにより、ハードドライブイメージからの復元が可能になります。

ファイルレベルバックアップとは?

ファイルレベルバックアップとは、データを個別のファイルに整理する手法です。これにより、ソースマシンからバックアップストレージへ、異なるデータファイルを便利に

バックアップ手法とは?

バックアップ手法とバックアップの種類を混同しないように注意してください。後者が様々なバックアップ手法に焦点を当てるのに対し、前者はデータをバックアップするための異なるアプローチそのものを指します。バックアップ技術と考えることもできます。

 

主なデータバックアップ方法は以下の3つです:ファイルレベルバックアップ、システム状態バックアップ、イメージベースのバックアップ、アプリケーション対応バックアップ、VMバックアップ。

新ディザスターリカバリー・チェックのヒント

●AIによる異常検知を組み込む: これらのツールは、システムのパフォーマンスを監視し、潜在的な障害やサイバー攻撃が災害に拡大する前に、早期警告の兆候を検出することができます。

 

●イミュータブル・バックアップの活用: たとえ管理者であっても、バックアップを変更したり削除したりすることはできません。これにより、バックアップデータの暗号化や破壊を試みるランサムウェア攻撃から保護されます。

 

●段階的なアプリケーション・リカバリ戦略を確立する: ビジネスへの影響に基づいて復旧作業の優先順位を決めます。クリティカルなアプリケーション(金融取引、顧客データベースなど)は、ほぼ瞬時にリカバリできるようにする。

 

●ジャスト・イン・タイム(JIT)アクセス制御を導入する: JITを使用して、災害復旧ツールや認証情報へのアクセスを制限する。JITは、必要なときにのみ権限を付与し、使用後は自動的に権限を取り消す。これにより、内部脅威を最小限に抑えることができる。

 

●フェイルオーバー手順のスクリプト化を避ける: N2W などのツールを使用してフェイルオーバー処理を自動化することで、人的ミスを減らし、復旧時間を短縮します。DRドリルを自動的に実行し、信頼性を確保します。

 

AWS環境の災害対策(DR)計画を立てる際に考慮すべきヒント

●DR運用にIAMポリシーを組み込む:DR運用や機密性の高いリカバリリソースへのアクセスを制限する、IAMの専門ポリシーを作成します。これによりセキュリティのレイヤーが追加され、権限のある担当者だけがフェイルオーバーを開始したり、重要なデータにアクセスしたりできるようになります。

●長期データ保持にはS3 Glacier Deep Archiveを利用:アクセス頻度の低いバックアップデータをS3 Glacier Deep Archiveに保存することで、ストレージコストを大幅に削減しながら、必要な時に数時間以内にデータを取得できる能力を維持できます。これは、DR計画の一環として重要なデータを長期間保持するのに最適です。

●重要なワークロードに対してマルチリージョンレプリケーションを実装する:Amazon S3 Cross-Region ReplicationやDynamoDB Global Tablesなどのサービスを使用して、最も重要なワークロードに対してマルチリージョンレプリケーションを設定します。これにより、AWSのリージョン全体が利用できなくなった場合でも、データとアプリケーションは利用可能な状態を維持できます。

●N2WSを活用したDRフェイルオーバーの自動化:N2WS Backup & Recoveryを使用して、新しいインスタンスの起動、DNSレコードの更新、ネットワーク設定の再構成などのフェイルオーバープロセスを自動化します。N2WSは、災害復旧の管理に合理化された信頼性の高いアプローチを提供し、手動介入を減らし、迅速な復旧を実現します。

●AWS Outposts を活用したハイブリッド DR ソリューションの検討:オンプレミスインフラストラクチャを大量に保有する組織では、AWS Outposts を使用して AWS サービスをデータセンターに拡張することを検討してください。このハイブリッドアプローチにより、オンプレミスのデータ主権とコンプライアンスを維持しながら、AWS の DR 機能を活用することができます。

貴社の災害復旧は対応できますか? 第3部 – 柔軟性による回復力の向上

災害復旧において、回復力は究極の目標です。 私たちは、復旧においてピード整合が果たす重要な役割について検討してきましたが、さらに重要な要素がもう一つあります。それは「柔軟性」です。

真の回復力とは、復旧のスピードや正確さだけに依存するものではありません。あらゆる状況、あらゆる環境、あらゆる課題に適応する能力に依存するものです。今日のハイブリッドかつマルチクラウドの世界では、柔軟性こそが俊敏性を引き出し、ビジネスの継続性を確保するための鍵となります。

見落とされがちなレジリエンスの要素

適応能力はレジリエンスの特長です。 企業がハイブリッドおよびマルチクラウド環境に移行するにつれ、硬直的なリカバリソリューションは足かせとなります。 現代のディザスタリカバリには、以下の機能が必要です。

  • クラウドの自由: 機敏性を維持するには、複雑性を増すことなく、パブリック、プライベート、ハイブリッドクラウド間でリカバリできることが必要です。
  • スケーラビリティ: ビジネスとともに成長し、進化する需要に対応するソリューション。
  • 相互運用性:既存のツールやシステムとシームレスに統合し、危機発生時の混乱を最小限に抑えます。

 Zerto は、これらの分野において比類ない柔軟性を提供し、お客様の復旧戦略が、必要な場所で、必要な時に、必要な方法で機能することを保証します。

柔軟性がレジリエンスの要である理由

現代のIT環境は、決して静的なものではありません。企業はオンプレミスのインフラストラクチャ、パブリッククラウド、プライベートクラウド、そしてますます増え続けるハイブリッド環境で業務を行っています。これに加えて、進化する脅威の状況、コンプライアンスの要求、そしてかつてないほど迅速なイノベーションのプレッシャーがあります。柔軟性のない災害復旧(DR)戦略では、これらの課題に対応することはできません。

柔軟性のないことによるリスク:

  • ベンダーロックイン:単一のプラットフォームに縛られることで、危機的状況下での対応能力が制限されます。
  • 移行中のダウンタイム:ワークロードの移動やインフラの近代化が、時間のかかる苦痛なプロセスになります。
  • 機会損失:迅速な適応ができないと、適応できる競合他社に遅れをとることになります。

柔軟性の実例

柔軟性は流行語ではなく、測定可能な利点です。災害復旧戦略に柔軟性があれば、以下のような復旧が可能になります。

  • どこでも
  • オンプレミス、クラウド、ハイブリッドのどの環境であっても、柔軟性があれば、ビジネスにとって最も理にかなった場所でリカバリを行う自由が得られます。Zerto を使用すれば、インフラストラクチャの制約やベンダーの要件に縛られることはありません。
  • いつでも
  • 災害は都合の良い時を待ってはくれません。リカバリも同様です。柔軟性があれば、計画的な移行時でも、計画外の停止時でも、必要な時にリカバリを行う自信が得られます。
  • 妥協なし
  • 柔軟性により、データはそのまま維持され、シームレスなリカバリが実現し、業務が中断することなく継続されます。 障壁を取り除き、チームが迅速に行動できるようにすることです。

選択の自由

Zertoでは、ソリューションの核となる部分に柔軟性を組み込んでいます。 この適応性は、IT環境が進化する中で特に価値があります。BroadcomによるVMwareの買収など、業界の大きな変化により、企業は新しい選択肢を模索する必要に迫られています。

価格、パッケージング、サポートに関する不確実性と格闘しているVMwareのお客様に対して、Zertoはシンプルかつ強力な代替案を提供します。当社のソリューションは、業界をリードするRTO(目標復旧時間)とRPO(目標復旧時点を維持しながら、お客様が選択したハイパーバイザーやクラウド環境へのシームレスな移行をサポートします。VMwareからの完全な移行であれ、マルチクラウド戦略のテストであれ、Zertoは移行に伴うダウンタイムのリスクを低減しながら、移行を可能にします。Zertoは、次のような機能を提供し、企業の復旧を支援します。

  • プラットフォームに依存しない:AWS、Azure、プライベートデータセンターなど、クラウドプロバイダーやオンプレミスのインフラストラクチャへの復旧、またはそれら間の復旧、あるいはそれら内での復旧が可能です。
  • シームレスなワークロードのモビリティ:災害復旧を緊急時だけでなく、計画的な移行、クラウドの導入、さらにはデータセンターの統合にも利用でき、ダウンタイムを最小限に抑えることができます。
  • 中断のないテスト: 回復テストを必要なときにいつでも実行し、日常業務に影響を与えることなく、コンプライアンスと準備態勢を確保します。
  • 継続的なデータ保護: 環境に関わらず、RPOとRTOを他に類を見ないレベルで確保します。

現実世界における柔軟性

例えば、多国籍繊維企業であるTenCate Protective Fabrics社では、クラウド戦略の変更の最中にあり、AWSからMicrosoft Azureへの移行が必要でした。Zertoを活用することで、同社はワークロードを移行し、地域製造拠点から水平型グローバルモデルにデータを移行しながら、6秒のRPOを実現することができました。

選択肢による回復力

柔軟性とは、今日の課題に対応するだけでなく、明日の未知の課題に備えることでもあります。Zerto を利用すれば、硬直したアーキテクチャやベンダーロックイン、時代遅れのソリューションに縛られることはありません。むしろ、リカバリ方法を選択する自由が得られ、ビジネスに適応する俊敏性と成功への自信が得られます。

自問してみてください。

  • 現在の復旧戦略は変化のペースに追いついていますか?
  • ダウンタイムやリスクなしに新しい環境やプラットフォームに切り替えることができますか?
  • 復旧方法を選択する自由がありますか?それとも、特定の運用方法に縛られていますか?

Zertoなら、選択の自由が手に入ります。

貴社の災害復旧は間に合いますか? 第2部 – 回復における真の回復力を実現

最初の記事「災害復旧はスピードについていけるか? 第1部 – スピードの必要性」では、災害復旧(DR)におけるスピードの重要な役割について考察しました。 スピードが重要なのは間違いありませんが、それはソリューションの一部にすぎません。 本当の回復力とは、シームレスで包括的な復旧を確実にするために、スピードを超えたものです。

スピードは方程式の一部に過ぎない:真のレジリエンスを実現する復旧

災害が発生した際には、1秒1秒が重要となります。スピードは不可欠ですが、それだけでは十分ではありません。真のレジリエンス、つまりビジネス、評判、将来を守るためには、迅速な復旧だけでは不十分であり、どのような危機的状況においても、正確性、信頼性、俊敏性を備えた復旧能力が求められます。

多くの組織がここでつまずきます。 彼らは、RPOやRTOだけに注目し、スピードはパズルのほんの一部に過ぎないことに気づいていません。 回復のスピードだけでなく、「安全かつ柔軟に回復できるか」という点も重要です。 なぜなら、推測や見込みで回復作業を行うことは、回復とは言えないからです。

回復力の方程式

回復力とは、妥協することなくビジネスを継続できる形で回復する能力です。これを3つの要素からなる三角形として考えてみましょう。

  • スピード: もちろん、これは非常に重要です。復旧に時間がかかれば、金銭的な損失、評判の低下、顧客の不満につながる可能性があります。
  • 完全性: 復旧したデータが破損していたり、不完全であったり、信頼できないものでは、迅速な復旧も意味がありません。
  • 柔軟性: デジタル環境は常に変化しており、復旧ソリューションは、新たな課題、環境、脅威に迅速に対応できなければなりません。

スピードだけではスタートラインに立つことができても、回復力があればレースを続けることができます。

リカバリギャップの危険性

多くのDRソリューションはスピードを約束しますが、データの整合性という重要なニーズには対応していません。たとえば、スナップショットベースのリカバリでは、災害発生前の特定の時点、数時間、あるいは数日前の状態にシステムを復元できるかもしれません。しかし、その欠落した数時間内に作成されたデータはどうなるのでしょうか?その過程で失われたトランザクション、顧客とのコミュニケーション、業務上の洞察はどうなるのでしょうか?

これは単なる技術的な問題ではなく、ビジネスリスクです。

  • 顧客の信頼を損なう: 復旧ソリューションが十分でなかったために、顧客のデータが失われたと伝えることを想像してみてください。
  • コンプライアンス違反による罰金リスクにさらされる: 規制当局は、データの紛失や誤処理を「復旧ギャップ」という言い訳として認めません。
  • ビジネスがさらなる攻撃にさらされる: 復旧が不完全だと、敵対者にバックドアを開いたままにしてしまうことになります。

真のレジリエンスとは、すべてのデータ・バイトが記録され、すべてのシステムが稼働していることを確認しながら、自信を持って復旧できることを意味します。

Zertoによるレジリエンスの実現

Zertoでは、スピードは方程式の一部に過ぎないことを理解しています。そのため、当社のソリューションは以下を提供するように設計されています。

  • 継続的なデータ保護リアルタイム・レプリケーションにより、リカバリ・ギャップを削減し、データの整合性を確保します。
  • 自動化されたオーケストレーション:複雑な処理を代行するツールにより、リカバリを簡素化します。
  • クラウドの俊敏性:クラウドプロバイダーへの復旧、クラウドプロバイダーからの復旧、クラウドプロバイダー間の復旧を、同じレベルのスピードと信頼性で実現します。
  • プロアクティブなテスト:自動化およびオーケストレーションされた無停止フェールオーバーテストにより、最も必要な時に、お客様の復旧計画が完璧に機能することを検証します。

スピード、整合性、柔軟性のいずれかを選択しなければならない競合他社とは異なり、Zertoはすべてを提供します。これにより、迅速かつ包括的な復旧が可能になります。

レジリエンスの実践

当社のお客様であるグローバルな繊維技術企業は、データと業務を脅かすランサムウェア攻撃に直面しました。Zertoを使用することで、データ損失はわずか10秒で、数分でシステムを復元することができました。Zertoを使用する前の攻撃では、12時間分のデータを失い、復旧に2週間を要しました。

不完全な復旧の真のコスト

では、なぜ組織は完全なレジリエンス(スピード、完全性、柔軟性)のソリューションを選ばないのでしょうか? 時代遅れの復旧方法に頼っている組織は、DRソリューションを最新化する初期費用に重点を置いていることが多いのです。 しかし、最新化しないことによるコストはどれほどでしょうか?

  • 収益の損失:ダウンタイムが1分増えるごとに、収益が減少します。
  • 評判の低下:危機的状況下で業務を継続できない企業に対して、顧客は辛抱強くありません。
  • 規制による罰則:コンプライアンス違反は、特にヘルスケアや金融業界などでは、多額の罰金につながる可能性があります。

将来のためのレジリエンスの構築

最新型のDRは、単にスピードだけを追求するものではありません。 あらゆる危機に耐え、自信を持って回復し、次に何が起ころうとも適応できるビジネスを確保することが目的です。 Zertoを使用すれば、高速なリカバリが実現するだけでなく、包括的なリカバリが実現します。

そこで、自問してみてください。

  • 貴社のリカバリソリューションは、回復力(スピード、整合性、柔軟性)を備えていますか?
  • 今日の複雑なハイブリッド環境に適応できますか?
  • 災害が発生した際に、生き残るだけでなく、成功を収める準備はできていますか?

Zertoなら、その答えはイエスです。

貴社の災害復旧はスピードについていけますか? 第1部 – スピードの必要性

誰もが経験したことがあるでしょう。ビデオのクライマックスで恐ろしいスピンホイールが回り続けるのを眺めたり、フライトの遅延が画面に表示され、空港のゲートで足止めされたり、最悪の場合、緊急時にシステムがダウンし、最も必要な時に利用できなくなることがあります。このような瞬間は単なる不都合というだけでなく、最も洗練されたシステムであってもダウンタイムに対しては脆弱であることを思い知らされる瞬間でもあります。今日のハイリスクなデジタル経済において、ダウンタイムは世界中の企業にとっての弱点です。

ランサムウェア攻撃であれ、自然災害であれ、予期せぬシステム障害であれ、災害が発生すると、秒単位で時間が経過していきます。 1秒でも損失が増えれば、それだけ収益のリスクが高まり、信頼が損なわれ、顧客が他社に流れる可能性も高まります。 問題は、災害復旧(DR)計画が試されるかどうかではなく、ビジネスを存続させるのに十分な速さと信頼性があるかどうかです。

現代の復旧の現実:スピードと信頼性のどちらを優先するか?

競合他社の中には、DRにおいてはスピードだけでは危険であると主張する企業もあります。彼らは「あまりにも急いで、あまりにも速く復旧しようとすると、状況を悪化させる可能性がある」と主張しています。この考え方は誤った選択肢を示唆しており、復旧に関してはスピードと信頼性のどちらかを選択しなければならないと示唆しています。

Zertoでは、この考え方を根本的に否定しています。RPOとRTOオプションではなく、生命線です。迅速な対応とリカバリの整合性への信頼のどちらかを選択する必要はありません。実際、真のレジリエンスには両方が必要です。その理由は次の通りです。

  • ランサムウェアは待ってくれません。攻撃はエスカレートし、バックアップを標的とし、急速に広がっています。リカバリが遅い、または不完全であると、敵対者に混乱を引き起こす時間を与えることになります。
  • ためらいは高くつく:システムが停止する時間が1分増えるごとに、金銭的および評判上のダメージも増大します。復旧が遅いと、ただ痛手を被るだけでなく、事業継続と廃業の分かれ目になることもあります。
  • 信頼は準備から始まる:復旧とは、単にデータを復元することではなく、信頼を回復することです。DRソリューションは、結果をあれこれ考えずに迅速に復旧できる自信を与えてくれるものでなければなりません。

妥協のない復旧スピード

Zertoが他社と一線を画しているのは、信頼できる高速リカバリを実現する能力です。 当社は、スピードとデータ整合性のトレードオフを求めません。 Zertoの継続的データ保護(CDP)により、RPOはわずか数秒に短縮され、RTOは数分単位で達成できます。

競合他社は、定期的なスナップショットからのリカバリや、面倒な手動フェールオーバープロセスに頼っているかもしれませんが、これらのアプローチにはエラーが起こる余地が大きすぎます。 データにギャップが生じたり、数時間前の情報を復旧しなければならなかったり、プレッシャーのかかる状況下でシステムの検証に奔走したりすることになります。 Zertoは、以下の方法でこれらの脆弱性を低減します。

  • リカバリギャップの排除:CDPはあらゆる変更をリアルタイムで取得し、データの最新性と安全性を確保します。
  • フェイルオーバーの簡素化:自動化されたプロセスにより複雑性を軽減し、ビジネス復旧に集中できます。
  • リカバリ期間の短縮:ランサムウェア、人為的エラー、ハードウェア障害など、どのような問題が発生しても、Zertoはシームレスなリカバリを実現し、危機が発生したことさえ忘れてしまうほどです。

スピードと信頼:事例

例えば、グローバルな消費財メーカーである当社のエンタープライズ顧客がランサムウェア攻撃を受けた際、数分以内に業務を復旧・復元することができました。データギャップも発生せず、躊躇することもなく、何よりも顧客の信頼を損なうこともありませんでした。競合他社の場合、手動による遅い復旧プロセスや不完全なバックアップにより、数時間、あるいは数日間もオフライン状態になる可能性がありました。

何が危機に瀕しているのでしょうか?

あらゆる組織がこの現実に直面しています。次に災害が起こるのは「起こるか起こらないか」の問題ではなく、「いつ起こるか」の問題なのです。そして、災害が起こった際には、貴社のDR戦略が競争力を維持できるかどうかを決定します。DRが追いつかない場合、貴社のシステムが回復に苦戦している間に競合他社が追い越してしまい、すでに最下位に甘んじていることになります。

そこで、自問してみてください。

  • 貴社のリカバリソリューションは、最新の脅威のスピードに追いつくことができますか?
  • どのような状況であっても、自信を持ってデータと業務を回復する準備ができていますか?
  • スピードと信頼性を両立するパートナーがいますか?

結論:今こそ加速するとき

Zertoなら、単にリカバリするだけでなく、これまで以上に迅速かつスマートに、そして高い信頼性を実現できます。 遅い、時代遅れの手動プロセスに足止めされる必要はありません。 スピードが足かせになるのではなく、競争優位性となる今日のデジタル世界に適したリカバリを採用する時が来たのです。

フェイルオーバーとフェイルバック:違いは何か?

フェイルオーバーとフェイルバックは、予期せぬ障害が発生した場合でもITシステムの回復力を確保する、事業継続における2つの重要な概念です。 ビジネスが中断のない運用にますます依存するようになるにつれ、高可用性を維持し、ダウンタイムを削減するためには、この2つのプロセスを理解することが不可欠です。

このガイドでは、フェイルオーバーとフェイルバックが連携してシステムを保護する方法、実際の使用例、そしてビジネスニーズに合わせてこれらのメカニズムを実装する方法について説明します。

 

フェイルオーバーとは?

フェイルオーバーとは、プライマリシステムに障害が発生した際に、冗長システムまたはスタンバイシステムにシームレスに切り替えることを指します。 バックアップ環境に自動的に切り替えることで、ダウンタイムを最小限に抑え、サービスの可用性を維持するように設計されています。 パンクした際に備えてスペアタイヤを用意しておくようなものです。

フェイルオーバーの目的は、問題が発生した場合でも、業務を円滑に継続することです。SAN、NAS、ネットワークの世界では、複製されたストレージシステムへの切り替え、バックアップサーバーの起動、ネットワークトラフィックの再ルーティングなどがこれに該当します。

フェイルオーバーの仕組み

フェイルオーバーは、プライマリシステムを継続的に監視し、障害の兆候を検出します。この監視には、ハートビート信号、健全性チェック、その他の診断テストが含まれます。障害が検出されると、フェイルオーバーシステムが自動的にセカンダリシステムへの切り替えを開始します。

このプロセスは通常、以下のステップで構成されます。

  1. 検出:システムがプライマリシステム内の障害を特定します。
  2. 起動:セカンダリシステムが起動し、オンラインになります。
  3. リダイレクト:トラフィックと操作がセカンダリシステムにリダイレクトされます。
  4. 検証:フェイルオーバーが検証され、セカンダリシステムが正常に機能していることが確認されます。

例えば、クラスタ化されたサーバー環境では、1台のサーバーが故障した場合、クラスタ内の他のサーバーが自動的にその負荷を引き継ぎ、アプリケーションとサービスが引き続き利用可能になります。これがフェイルオーバーの仕組みです。

最新の導入事例では、同期レプリケーションや10秒間隔でシステム指標を監視する自動ヘルスチェックなどの先進技術により、フェイルオーバー時間を1分未満に短縮している例が多く見られます。

フェールオーバーおよびフェールバック導入のメリット

フェールオーバーおよびフェールバックを導入することで、企業には以下のような重要なメリットがもたらされます。

  • ダウンタイムの削減:システム障害が業務に及ぼす影響を最小限に抑え、重要なサービスの継続的な可用性を確保します。
  • データ保護:データを二次システムに複製することで、停電時のデータの損失や破損を防ぎます。
  • 信頼性の向上:冗長システムと自動リカバリプロセスを提供することで、ITインフラの全体的な信頼性と回復力を強化します。

これらのメリットは、顧客満足度の向上、収益損失の削減、業務効率の改善など、具体的なビジネス成果につながります。例えば、フェールオーバーとフェールバックを導入したeコマースサイトでは、プライマリサーバーが故障した場合でも顧客が引き続き購入を続けられるため、販売機会の損失を防ぎ、顧客の信頼を維持することができます。

フェールオーバーとフェールバックのベストプラクティス

フェールオーバーとフェールバックを効果的に導入するには、以下のベストプラクティスを考慮してください。

  • 定期的なテスト:フェールオーバーとフェールバックのテストを定期的に実施し、システムが正常に機能していること、およびリカバリープロセスが適切に文書化され理解されていることを確認します。
  • 自動化されたプロセス:フェールオーバーとフェールバックのプロセスを可能な限り自動化し、手動による介入を減らし、エラーのリスクを最小限に抑えます。
  • 包括的なモニタリング:すべての重要なシステムを包括的にモニタリングし、障害を迅速に検知してフェールオーバー手順を開始します。
  • 詳細な文書化:フェイルオーバーおよびフェイルバックのプロセスについて、手順、構成、連絡先情報などを含む詳細な文書を作成しておく。
  • データの同期:プライマリシステムとセカンダリシステム間のデータの同期が信頼性が高く効率的であることを確認し、フェイルオーバーおよびフェイルバック時のデータ損失を防ぐ。

これらのベストプラクティスに従うことで、企業はフェイルオーバーおよびフェイルバック戦略の効果を最大限に高め、あらゆる潜在的な混乱に備えることができます。

結論

効果的な災害復旧は、今日のデジタル環境における事業継続性を維持するために不可欠です。フェイルオーバーとフェイルバックのメカニズムは、ダウンタイムの短縮、データの完全性の確保、障害発生時のサービス継続の鍵となります。定期的なテスト、自動復旧、適切な文書化などのベストプラクティスに従うことで、企業はITインフラを強化し、ハードウェアやソフトウェアの障害発生時にデータ損失を回避または完全に最小化することができます。