VMware Cloud Foundation 9.1のProtection and Recoveryは、バックアップ製品の名前だけを覚える話ではありません。vSAN Snapshots、Replication、Protection Groups、オンプレのIsolated Recovery Environment、EDRによる復旧前検証を、インシデント時に動かせる順番へ落とす話です。
Broadcom/VMwareの公式資料では、VCF 9.1のサイバー復旧まわりに複数の更新が出ています。vSAN Protection and Recoveryの強化、Advanced Cyber Compliance 9.1の統合サイバー復旧、CrowdStrike Falcon連携、Protection and Recovery 9.1/9.1.0.0100のTechDocsが同じ流れにあります。この記事では、機能名の羅列ではなく、導入前にどの担当者が何を確認するかに絞ります。
Broadcom Watch JapanはBroadcomおよびVMware by Broadcomの公式サイトではありません。この記事は、2026年6月15日時点の公式公開情報をもとにした非提携の確認メモです。価格、契約条件、ライセンス範囲、サポート条件、実環境での復旧手順は、必ずBroadcomの最新資料、販売窓口、自社のBCP/セキュリティ審査で確認してください。
3行まとめ：Protection and Recovery 9.1で先に決めるのは保護対象、回復先、検証手順
どのVMを日常復旧、事業継続、ランサムウェア復旧の対象に入れるかを分けます。
vSAN、VMFS、NFSなどの保護元と、vSAN ESAの回復先を分けて確認します。
隔離、起動、検査、ステージング、復旧、再保護までを一つの作業場として設計します。
EDR検証、ログ、アプリケーション確認、承認条件を本番復帰の前にそろえます。
9.1.0.0100のような更新は、機能追加だけでなくセキュリティ強化や適用条件で読みます。
vSAN SnapshotsやReplicationは単独の機能ではなく、復旧候補を安全に戻す運用の一部として扱います。
- Protection and Recovery 9.1は、vSAN SnapshotsやReplicationだけで完結する機能ではなく、保護対象、回復先、Clean Room、復旧前検証、再保護までをつなぐ運用として読む必要があります。
- VCF 9.1では、vSAN、VMFS、NFSなど複数の保護元からvSAN ESAの回復先へ集約する考え方、タグによるProtection Group、階層型Snapshot Retention、Manual Replica Seedingが重要になります。
- CrowdStrike Falcon連携やACCの統合サイバー復旧は「安心材料」ではなく、本番へ戻す前に何を検査し、誰が承認し、どのログを残すかを決めるための材料です。
今回の需要シグナルは、2026年5月以降のVCF 9.1公式更新にあります。特に5月14日のVMware Cloud Foundation Blogは、vSAN Protection and Recoveryの強化を、architectural flexibility、sovereign cyber resilience、operational scaleという3つの軸で説明しています。6月に入ってからは、Protection and Recovery 9.1.0.0100やCyber Recovery関連のTechDocs更新も確認できます。
一方で、直近のBroadcom Watch Japanでは、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-49-vcf-91-vsan-storage-policy-stretch-ops-check/" rel="noopener">VCF 9.1のvSANストレージ設計</a>や、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-43-vcf-private-ai-services-nsx-vds-supervisor-check/" rel="noopener">Private AI ServicesのSupervisor構成</a>をすでに扱っています。この記事では、vSANの一般的なStorage Policyではなく、保護と復旧の運用に焦点を移します。
vSAN Snapshotsだけでなく復旧ワークフローとして読む
VCF 9.1のProtection and Recoveryを読むとき、最初に見るべきなのは「スナップショットを取れるか」ではありません。どのVMをどのProtection Groupへ入れ、どのRPOとRetentionを選び、どこへ複製し、復旧時にどの環境で検証するかです。
公式ブログは、VCF 9.1でvSAN Protection and Recoveryが、vSANだけでなくVMFSやNFSを含む複数の保護元から、vSAN ESA clusterを回復先にするmulti-source replicationを扱えると説明しています。これは、既存環境をすべて一気にvSANへ寄せる話ではなく、回復サイト側をどう設計するかという話です。
根拠
確認した一次情報は、Broadcom TechDocsのProtection and Recovery 9.1 Release Notes、Protection and Recovery 9.1.0.0100 Release Notes、VMware Cloud Foundation BlogのvSAN Protection and Recovery強化記事、VCF 9.1発表記事、Advanced Cyber Compliance 9.1記事、CrowdStrike連携記事です。
注意点
復旧機能の記事では、つい「ランサムウェア対策ができる」と短く言いたくなります。ただし実際の復旧可否は、保護対象の選定、Snapshot Retention、隔離環境、EDR検証、承認フロー、再保護、訓練頻度に依存します。この記事では、必ず復旧できるという断定はしません。
公式資料で確認済みの範囲と未確認に残す範囲
公式資料で確認できるのは、VCF 9.1での機能方向、vSAN Protection and Recoveryの主な強化、ACC 9.1の統合サイバー復旧、CrowdStrike Falcon連携、9.1.0.0100のセキュリティ強化です。
一方で、個別環境の契約でどのAdvanced Serviceを利用できるか、既存のCrowdStrike契約をどう扱うか、どのRTO/RPOが達成できるか、どの復旧手順が監査に耐えるかは、公開記事だけでは決められません。販売パートナー、Broadcomの契約資料、セキュリティ部門の承認を合わせて確認してください。
vSAN SnapshotsとReplicationで保護対象をどう分けるか
テンプレート名だけで選ばず、RPO、復旧深度、タグ運用、初回同期の制約を自社の復旧設計へ変換します。
Protection and Recovery 9.1で最初に棚卸しするのは、製品画面ではなく保護対象です。どのVMが事業継続上の優先対象か、どのVMは日常の運用復旧でよいか、どのVMはランサムウェア復旧の候補に入れるかを分けます。
VCF 9.1のvSAN Protection and Recovery強化では、multi-source replication、Protection Groupのタグ対応、Snapshot Retentionの階層化、Manual Replica Seedingが目立ちます。これらは全部を一度に使うための機能ではありません。自社の復旧設計でつまずいているところに対応させて読むと、判断しやすくなります。
Protection GroupsをVM名だけでなくタグでも扱う
公式ブログでは、Protection GroupのメンバーシップにvSphere Tagsを使える点が説明されています。VM名の静的な指定、ワイルドカードのような動的な名前指定に加え、タグで保護対象を選べると、アプリチームや業務重要度ごとの分類を反映しやすくなります。
たとえば、tier-1、finance、regulated-data、ransomware-recovery-candidate のようなタグ運用が既にあるなら、保護対象の選定と変更履歴をつなげやすくなります。逆にタグ運用が曖昧な環境では、便利な機能ほど誤ったVMを保護対象に入れたり、必要なVMを落としたりするリスクがあります。
確認項目
保護対象の棚卸しでは、VM名、アプリ所有者、業務重要度、利用ストレージ、依存サービス、RPO、RTO、復旧順序、タグ、除外理由を同じ表に入れます。ここを曖昧にしたままProtection Groupを作ると、復旧訓練で「なぜこのVMが入っていないのか」を説明できません。
下振れ要因
タグがチームごとに勝手に作られている、古いVMが残っている、同じアプリのVMが複数の命名規則に分かれている、退役予定VMが保護対象に混ざっている。この状態でタグベースのProtection Groupを使うと、自動化の便利さがそのまま誤設定の速さになります。
Snapshot RetentionはRPOと復旧深度で読む
VCF 9.1のvSAN Protection and Recoveryでは、単純なFIFOだけでなく、Hourly、Daily、Weekly、Monthlyのような階層型Retentionが説明されています。公式ブログでは、Default、Ransomware recovery、Short-term retentionのようなテンプレート例にも触れています。
ここで大切なのは、テンプレート名だけで選ばないことです。ランサムウェア復旧では、直近のスナップショットがすでに汚染されている可能性があります。より古い復旧点を残す意味はありますが、その分の容量、検証時間、復旧判断の複雑さも増えます。
評価基準
Retentionは、保存数の多さではなく、復旧候補を検証できる幅で評価します。RPO、保持期間、容量、検証に使えるClean Roomのリソース、EDRスキャン時間、承認者の可用性を同じ条件で見てください。
オンプレClean Roomを用意する前に決めること
- 1検知
ランサムウェアイベントや異常を受けて、保護VMと復旧候補を選定します。
- 2隔離起動
Isolated Recovery Environmentで復旧候補を起動し、本番ネットワークから切り離します。
- 3スキャン
EDR sensorやログ確認で、マルウェア、認証情報、通信、アプリケーション状態を確認します。
- 4ステージング
クリーンと判断した候補を復旧用に整え、必要な設定差分と承認記録を残します。
- 5復旧
本番または二次サイトへ戻す前に、承認者、切り戻し条件、利用者影響を確認します。
- 6再保護
復旧後のVMを再び保護対象に入れ、フェイルバックや次回テストの条件を更新します。
DRは起動できるかが中心ですが、ランサムウェア復旧ではクリーンかどうかと再感染を防げるかが判断軸になります。
VCF 9.1のサイバー復旧で強調されているのが、オンプレのIsolated Recovery Environment、つまりClean Roomです。公式ブログは、パブリッククラウドに依存しない、顧客所有・顧客管理の回復環境を作れる点を説明しています。
ただし、Clean Roomは「別の場所に復元する箱」ではありません。感染が疑われる本番環境から切り離し、復旧候補を起動し、EDRで検査し、ステージングし、復旧し、再保護するための作業場です。運用設計なしに用意しても、インシデント時には使い切れません。
DRとランサムウェア復旧を同じ手順にしない
災害復旧では、正常だった時点のデータを別サイトで起動できるかが中心になります。ランサムウェア復旧では、それだけでは足りません。復元したVMが本当にクリーンか、認証情報やスクリプトが悪用されていないか、復旧後に再感染しないかを確認する必要があります。
公式ブログは、ランサムウェアイベントの検知後、保護VMをIsolated Recovery Environmentのvalidation stateへ置き、EDR sensorでスキャン/クリーンにし、staging stateでclean replicaを作り、recovered stateで二次サイト運用へ戻し、最後に再保護とフェイルバックへ進む流れを説明しています。
条件
Clean Roomを検討する前に、少なくとも隔離ネットワーク、DNS/認証の扱い、EDR sensorの導入方法、ログの保存先、復旧候補の選定権限、本番復帰の承認者を決めます。セキュリティチームとインフラチームが別の手順書を持っている場合は、復旧訓練で必ず衝突します。
注意点
Clean Roomをオンプレに持つことは、データ主権や閉域要件に合う場合があります。ただし、オンプレに置けば自動的に安全になるわけではありません。攻撃者が本番だけでなく復旧サイトの認証情報や管理経路も握っている場合、復旧基盤自体が狙われます。
ACC add-onやSRMの役割を分ける
公式ブログは、vSAN Protection and RecoveryのReplication機能がSRMを通じてSite Recoveryの機能として使われること、またVMware Advanced Cyber Compliance add-onがSite Recoveryと包括的なCyber Recoveryを提供することを説明しています。
ここは導入判断で混同しやすい場所です。VCF 9.1本体、vSAN Protection and Recovery、SRM、ACC、CrowdStrike Falcon、VMware Live Recoveryは、読み手から見ると一つの復旧ストーリーに見えます。しかし契約、ライセンス、運用担当、障害時の問い合わせ先は分かれる可能性があります。
確認項目
導入前には、どの機能が既存契約に含まれるか、どの機能がAdvanced Serviceまたは別契約か、SRMやACCを誰が管理するか、CrowdStrike側のライセンスや運用権限を誰が持つかを表にします。ここを本文で断定せず、公式資料と契約で確認する前提にします。
CrowdStrike連携を「あると安心」で終わらせない
Clean Room内のVMへFalcon sensorを入れる方法と、既存契約で扱える範囲を確認します。
EDR結果だけでなく、ファイル差分、認証イベント、ネットワーク通信、アプリケーション整合性も見ます。
検証結果、システムログ、SIEM転送、インシデント管理ツールへの記録先を決めます。
誰が本番復帰を許可し、誰が停止判断を出せるかをセキュリティ運用に接続します。
クリーンコピーを戻した後、保護対象、保持期間、次回テスト条件を更新します。
検知ゼロは絶対安全を意味しないため、EDR結果と運用ログ、承認記録を合わせて判断します。
VCF 9.1のサイバー復旧で注目されやすいのがCrowdStrike連携です。VMware Cloud Foundation BlogのCrowdStrike連携記事では、ACC 9.1がオンプレのisolated clean roomsに統合サイバー復旧ワークフローを持ち、CrowdStrike Falcon sensorをClean Room内のVMへ注入して検証に使う流れが説明されています。
この話を「CrowdStrikeに対応した」とだけ読むと、導入判断としては弱くなります。重要なのは、復旧前に何を検査し、どの結果なら本番へ戻してよいと判断し、どのログを監査証跡として残すかです。
EDR検証は復旧前の承認条件に入れる
復旧候補のVMを起動できたとしても、それだけで本番復帰させるべきではありません。公式ブログは、restore point candidatesの特定、Clean Roomでのinstant power-on、CrowdStrike Falcon sensorによる検証、clean copiesの確認後のproductionへのfailbackという流れを説明しています。
実務では、EDRが検知しなかったことをどう扱うかも決めておく必要があります。検知ゼロは「絶対に安全」の意味ではありません。ログ、ファイル差分、認証イベント、ネットワーク通信、アプリケーション整合性を合わせて見ます。
評価基準
本番復帰の承認条件には、EDR検証結果、システムログ、アプリケーションのsmoke test、認証情報のローテーション状況、隔離解除の承認者、再保護の完了を入れます。復旧の速さだけをKPIにすると、汚染されたVMを早く戻すリスクが残ります。
未確認に残すこと
CrowdStrike Falconの既存契約をどのように復旧サイトへ適用できるか、追加費用や利用条件がどうなるかは、公開ブログだけで判断しないほうが安全です。公式ブログには既存ライセンスの持ち込みに触れる説明がありますが、実際の契約条件は自社契約、販売窓口、CrowdStrike/Broadcom側の最新条件で確認してください。
既存セキュリティ運用との接続を決める
セキュリティチームが日常的に使っているSIEM、EDRコンソール、インシデント管理ツール、承認ワークフローと、Clean Room内の検証結果が分断されていると、復旧判断は遅れます。復旧サイトで検知したイベントをどこへ転送し、誰が見て、誰が本番復帰を止められるのかを決めておきます。
Broadcom TechDocsには、Cyber Recovery Best Practicesやイベント転送に関するページもあります。記事本文で手順を細かく再現するより、導入前の設計では「復旧イベントをセキュリティ運用へどう渡すか」を先に決めるほうが実務に効きます。
9.1.0.0100とTechDocs更新をどう読むか
- Release Notes
Protection and Recovery 9.1と9.1.0.0100の更新内容、既知問題、対象範囲を確認します。
- Security
セキュリティ強化や修正の有無を見て、復旧基盤の更新優先度を判断します。
- Install and Upgrade
インストール、アップグレード、互換性、既存環境への影響を変更手順に落とします。
- Guidance
Cyber Recovery Best PracticesやRansomware Recovery Workflowの条件を読み直します。
- 非破壊検証
復旧候補の選定、Clean Room起動、ネットワークマッピング、EDR検証、承認フローを定期テストに入れます。
復旧手順は作った時点ではなく、繰り返し試した時点で初めて運用になります。
Protection and Recovery 9.1.0.0100 Release Notesは、派手な発表会ニュースではありません。ただし、復旧基盤に関わる更新は、機能名よりも更新内容、適用条件、既存環境への影響を確認する必要があります。
2026年6月15日時点で確認できるTechDocsの検索情報では、9.1.0.0100は各種セキュリティ強化を含むリリースとして示されています。復旧基盤はインシデント時の最後の頼みになりやすいため、セキュリティ更新の扱いを後回しにしないほうがよいです。
パッチは機能追加だけで判断しない
復旧系のパッチは、ユーザーから見える機能が大きく増えないこともあります。それでも、セキュリティ強化、互換性、アップグレード手順、既知問題が変わる可能性があります。
VCF 9.1の本体移行や更新順序をまだ整理していない場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-28-vcf-52x-to-91-upgrade-planner-check/" rel="noopener">VCF 5.2.xから9.1へ移行前に確認する記事</a>を先に読み、Management Services、NSX、vCenter、ESXの更新順序と合わせて見るとよいです。
確認項目
9.1.0.0100を見るときは、対象コンポーネント、前提バージョン、インストール/アップグレード手順、既知問題、セキュリティ強化、ロールバック方針、既存Protection Groupsへの影響、回復サイト側の更新要否を確認します。
迷った時の確認順
最初にRelease Notes、次にInstallation and Upgrade、次に既存DR/Cyber Recovery guidance、最後に自社構成の変更手順へ戻ります。コミュニティ投稿や二次解説は、公式資料で読み落とした観点を探すために使い、事実認定の根拠にはしません。
非破壊検証を定期テストに組み込む
Broadcom TechDocsの検索情報では、VCF 9.1には専用のRansomware Recovery Workflowがあり、定期的な検証が必要であることが示されています。これは重要です。復旧手順は、作った時点ではなく、繰り返し試した時点で初めて運用になります。
非破壊検証では、本番へ影響を出さずに、復旧候補の選定、Clean Room起動、ネットワークマッピング、EDR検証、ログ確認、承認フローまでをなぞります。テストで失敗した点は、復旧機能の失敗ではなく、事前に見つけられた運用リスクとして扱います。
導入判断メモ：担当チームごとに渡す一文
小さなProtection GroupからPoCを始め、運用手順と権限分界を確認します。
保護元、回復先、Snapshot Retention、初回同期、容量計画を復旧要件に合わせます。
Clean RoomでのEDR検証、ログ転送、承認条件、本番復帰停止権限を決めます。
災害復旧とランサムウェア復旧を分け、訓練で確認する手順と判断基準をそろえます。
ACC add-on、SRM、CrowdStrike契約、証跡保存、サポート条件を導入前に確認します。
すぐPoCへ進む場合でも、契約、承認、ログ、復旧後の再保護まで同じ言葉で確認しておきます。
Protection and Recovery 9.1は、単一チームだけでは導入できません。プラットフォーム、ストレージ、セキュリティ、DR/BCP、監査、契約担当が同じ言葉で話せるように、最後はチーム別の一文に落とします。
すぐPoCに進めやすい条件
vSANまたはVCF 9.1の検証基盤があり、保護対象候補のVMが決まっており、回復サイトのリソースを確保でき、セキュリティチームがEDR検証へ参加できる。この条件があるなら、机上の資料読みだけで止めず、小さなProtection GroupからPoCに進めやすいです。
プラットフォームチームに渡す一文
Protection and Recovery 9.1は、VCF 9.1の復旧運用をvSAN Snapshots、Replication、Clean Room、EDR検証まで広げるための設計テーマとして扱い、VCF本体の更新順序やManagement Servicesの準備と合わせて確認する。
ストレージチームに渡す一文
vSAN、VMFS、NFSなど保護元の違いと、vSAN ESA回復先の設計を分け、Protection Groups、Retention、Replica Seeding、容量、再同期、回復サイトの性能を同じ表で見る。
セキュリティチームに渡す一文
Clean Roomで復旧候補を起動できることより、EDR検証、ログ保存、承認条件、認証情報の扱い、本番復帰の停止権限を先に決める。
棚卸し後に進めたほうがよい条件
保護対象が未整理、タグ運用が曖昧、DRサイトの権限が分かれている、EDR運用とインフラ運用が別々のチケットで動いている、契約上のACC/CrowdStrike利用範囲が未確認。この場合は、PoC前に棚卸しを挟んだほうがよいです。
DR/BCP担当に渡す一文
通常の災害復旧とランサムウェア復旧を同じ手順にせず、Clean Roomでの検証、ステージング、再保護、フェイルバックまでを訓練シナリオに入れる。
監査・契約担当に渡す一文
ACC、SRM、VMware Live Recovery、CrowdStrike Falconなど、復旧ストーリーを構成する要素の契約範囲、ログ、承認記録、定期検証結果を残せる形にする。
下振れ要因
もっとも危ないのは、復旧機能を導入しただけで復旧能力が上がったと見なすことです。保護対象、復旧点、Clean Room、EDR、承認、再保護のどこかが未設計なら、インシデント時には人が迷います。
更新履歴・運用メモ
復旧基盤は導入後の更新や契約条件に影響されるため、公開情報と自社環境の確認を分けて扱います。
- 確認日：2026年6月15日JST。
- 確認対象：Broadcom TechDocsのProtection and Recovery 9.1 Release Notes、Protection and Recovery 9.1.0.0100 Release Notes、Cyber Recovery関連ページ、VMware Cloud Foundation BlogのVCF 9.1/vSAN Protection and Recovery/ACC/CrowdStrike関連更新。
- 未確認範囲：実環境のVCF Operations画面、SRM/ACC設定、CrowdStrike契約条件、復旧訓練ログ、個別のRTO/RPO達成値。
- 適用前には、該当バージョンのTechDocs、契約資料、サポート条件、セキュリティ部門の承認手順を開き直してください。
2026年6月のBroadcom/VMware更新を継続して追う場合は、<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>が入口になります。更新通知を受け取りたい場合は、読了後の導線として<a href="https://avgo-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>も使えます。
次に読むなら
参照した主な情報源
- Broadcom TechDocs, "Protection and Recovery 9.1 Release Notes"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/release-notes/protection-and-recovery-91-release-notes.html
- Broadcom TechDocs, "Protection and Recovery 9.1.0.0100 Release Notes"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/patch-releases/protection-and-recovery-9-1-0-0100-release-notes.html
- VMware Cloud Foundation Blog, "VMware vSAN Protection and Recovery Enhancements for VCF 9.1"。確認日：2026年6月15日。https://blogs.vmware.com/cloud-foundation/2026/05/14/vmware-vsan-protection-and-recovery-enhancements-for-vcf-9-1/
- VMware Cloud Foundation Blog, "Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience"。確認日：2026年6月15日。https://blogs.vmware.com/cloud-foundation/2026/05/05/announcing-vcf-9-1-modern-private-cloud-built-for-efficiency-and-resilience/
- VMware Cloud Foundation Blog, "Continuous Compliance, Integrated Cyber Recovery and Enhanced Platform Security for VCF 9.1"。確認日：2026年6月15日。https://blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1/
- VMware Cloud Foundation Blog, "VMware and CrowdStrike Deliver New Integration for Cyber Recovery Workflows"。確認日：2026年6月15日。https://blogs.vmware.com/cloud-foundation/2026/05/05/vmware-and-crowdstrike-announce-partnership-to-deliver-new-integration-for-cyber-recovery-workflows/
- Broadcom TechDocs, "Guidelines for Adding Cyber Recovery to an Existing Disaster Recovery Site"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/using-on-premises-ransomware-recovery/guidelines-for-adding-cyber-recovery-to-an-existing-disaster-recovery-site.html
- Broadcom TechDocs, "Testing the Secure Configuration for Non Disruptive Validation"。確認日：2026年6月15日。https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/using-on-premises-ransomware-recovery/guidelines-for-adding-cyber-recovery-to-an-existing-disaster-recovery-site/testing-the-secure-configuration-for-non-disruptive-validation.html