バックアップに関する企業の成熟度には幅がある。初期段階にある企業は、セキュリティ監査などを通すための形式的な証跡作りとしてバックアップを取得し、データをコピーすれば作業完了と見なす。対照的に成熟度の高い企業は、事業継続戦略の一部としてバックアップを捉えている。具体的には、システム間の依存関係の把握や復旧手順の自動化、予備システムに切り替えるフェイルオーバーの予行演習などが含まれる。

　Gartnerのアナリストであるフィンタン・クイン氏は、「分散型のシステム構成や現代のアプリケーション群の複雑さに手を焼く企業は後を絶たない」と指摘する。そうした企業は、復旧能力の確保を後回しにしがちだ。企業の投資判断は復旧要件に追い付いていないのが現状であり、IT担当者は復旧の仕組みより、ストレージの性能指標やセキュリティ機能に注目しがちだという。

　「復旧の自動化よりも、不変性やネットワークからの隔離といった流行語への関心が依然として強い」（クイン氏）

　企業が点在するバックアップシステムの一元化を図るようになる中で、これは大きな障壁となる。クイン氏によれば、大半の企業はオンプレミスインフラとクラウドサービス全体を単一のダッシュボードで可視化し、制御することを目指している。その結果、標準搭載のバックアップツールからサードパーティー製品へと乗り換え、管理体制の標準化と一貫したセキュリティ基準の適用を試みる動きが一般的になりつつある。

　成熟度の高い企業はさらに一歩先を行く。そうした企業は「データのバックアップ」と「サービス全体の復旧」を明確に区別して扱う。この考え方は、複雑なITインフラをサイバー攻撃から復旧させる取り組みにも当てはまる。

　「改ざん不可能なバックアップを保持するだけでは不十分だと、成熟した企業は気付いている」とクイン氏は述べる。

バックアップの成功＝サービスの復旧ではない

　バックアップに真剣に取り組む企業であっても、技術的な壁に直面する。現代のクラウドサービスは、単独で完結するデータの集合体ではない。外部で管理されていたり、動的に割り当てられたりする周辺の構成設定に依存しており、標準的なバックアップではそれらを捉え切れないのだ。復旧作業が頓挫するのは、まさにこの部分だ。

　調査会社Forrester Researchのプリンシパルアナリスト、ブレント・エリス氏は、この根本原因を「誤った同一視」と表現する。いまだに復旧のゴールを「サービスが稼働できる状態になったこと」ではなく、「データが元に戻ったこと」だと捉える企業が存在するという。

　「復旧計画に欠けがちなのは、サービス間の依存関係を明確に示した構成図と、それを正しい順序で再構築するための作業手順だ」とエリス氏は語る。

　エリス氏が典型例として挙げるのが、オーストラリアで国民的な確定拠出年金を運用する巨大基金UniSuperにおいて、2024年に発生したインシデントだ。同組織では、プライベートクラウドの設定作業中のミスが原因で、「Google Cloud」の契約全体が削除される事態に陥った。クラウドサービス内のデータと仮想マシンのバックアップは残っていたが、必要な顧客専用の設定が消失していたため、一から作り直さなければならなかった。「復旧に必要な情報が不完全な状態は、システムの設計次第でさまざまな形で表面化する」とエリス氏は説明する。

責任共有モデルの範囲と限界

　データの復元とサービスの復旧の間にあるギャップは、「クラウドサービスが停止した際、誰が復旧の責任を負うのか」という疑問をもたらす。ここで混乱の種になるのが責任共有モデルだ。「ベンダーに任せておけば何とかしてくれる」という期待は通用しない。大半の場合、ベンダーの責任範囲はインフラの稼働維持にとどまる。

　例えばMicrosoftとSalesforceは、いずれもデータ保護が責任共有モデルに基づくことを明記している。Microsoftは、クラウド型オフィススイート「Microsoft 365」の災害復旧用データはバックアップの代わりにはならず、あくまでコンテンツの現在の状態を維持するだけだと明言している。Salesforceも同様に、自社のバックアップはインフラレベルの災害復旧を目的としており、それ以外の状況でビジネスレベルのデータを復元することはできないと明記している。

　「企業はベンダーがサービスを復旧すると信じがちだが、契約上の義務は稼働維持であり、完全な復旧ではない。SaaSでは設定状態などを再構築せず、単にデータを戻すだけだ」とエリス氏は指摘する。データ保護が自社の責任であると理解している企業でさえ、SaaSの障害が長引いた場合には構造的な障壁にぶつかる。

　エリス氏は次のように述べる。「SaaSの内部構造は不透明であり、障害時に別のシステムへ移行してすぐ業務を再開するのは極めて困難だ。データ構造の再定義や連携の再構築が必要であり、ベンダーロックインの事実が復旧の遅れを招く」

　ストレージの性能だけではなく、クラウドの復旧能力を正しく評価するには、サービス間の依存関係、復旧手順の自動化、設定の復元などをカバーする機能を検討しなければならない。クイン氏とエリス氏は共通の課題を指摘する。それは、ツールを導入する企業が「データを引き出せるか」ばかりを問い、「サービスを稼働状態に戻せるか」をベンダーに確認していない点だ。

クラウドサービスの復旧を確実にするチェックリスト

　バックアップ製品の選定に際して、インフラの依存関係を評価し、サービスの完全な復旧能力を確保するためには、以下の質問項目をベンダーに投げ掛けるとよい。

• 製品はID、ネットワーク、周辺設定にまたがる依存関係をどのように特定し、文書化するのか
• 製品はどのように正しい順序でサービスを復元し、復旧作業が隅々までうまくいったことを検証するのか
• 製品はデータだけではなく、IDやワークフロー、システム連携など、SaaS構成要素のどの部分を完全に再設定できるのか
• データの復元が完了してもサービスが利用できない場合、ベンダーの義務範囲外となる責任は何か
• 復旧プロセスの中で、自動化されている部分と手作業で実施する必要がある部分の割合はどの程度か
• 製品はクラウドネイティブなアプリケーションの復旧テストをどのように実施し、現実に即した条件下でのテストはどの程度の頻度で実施するのか

　復旧は技術的な課題であると同時に、製品調達の課題でもある。データ保護機能しか評価しない企業は、被害を受けた主要機能を手作業で再構築する事態に陥りかねない。一方で、復旧の自動化や依存関係の復元、テスト機能について深く切り込む企業は、自社が購入するものを正しく理解している。そうした企業は、復旧プロセスの大部分を自動化しやすい立場にあると言える。「これはクラウドネイティブなシステムを利用し、厳格な復旧テストが求められる企業が真っ先に注目すべきポイントだ」とクイン氏は言い添える。