VMware Backup：ブロードコム買収後の現状

2年間にわたる顧客との電話会議

2023年11月にブロードコムがVMwareの買収を完了して以来、私はVMwareの顧客と数十回にわたり電話会議を行い、今後どうすべきかを模索してきました。 この24ヶ月間で、会話の内容は変化してきました。最初の6ヶ月間は、「実際にはどれほど深刻な事態になるのか？」という質問が中心でしたが、今では「どう対処すべきか？」という質問が主流となっています。バックアップアーキテクチャの決定は、多くのチームが認識している以上に、この2つ目の質問に深く関わっています。 

この記事は、ブロードコム買収後の環境において、VMwareのデータ保護をどのように考えるべきか尋ねてくる同業者の方々に、私が伝えるであろう内容です。まず、選択肢を左右するブロードコムに関する事実から説明します。次に、バックアップに関する意思決定をどのように変える必要があるかについて述べます。その後、依然として重要な技術的な基礎知識について解説します。最後に、私が話を聞いたほとんどのチームが当てはまる3つのシナリオを紹介します。

「ブロードコム買収後」が実際に意味すること

ブロードコムは2023年11月に買収を完了しました。最初のライセンス変更は2023年12月に実施され、その変更は2024年、2025年を経て、2026年まで続いています。 これらの変更が積み重なる結果、現在のVMwareは、多くの企業が数年前に導入した当時とは根本的に異なる商用ルールのもとで運営されるようになりました。

顧客とのあらゆる会話で話題に上る変更点は以下の通りです：

永久ライセンスの終了。年間サポート付き永久ライセンスは廃止されました。 すべての新しい利用権はサブスクリプションのみとなります。永久ライセンスをお持ちのお客様は、その更新を行うことができません。既存の導入環境は引き続き稼働しますが、拡張や更新を行うにはサブスクリプションへの移行が必要となります。

製品カタログが約168製品から4つのバンドルに統合されました。 従来の製品ラインナップは、VMware Cloud Foundation（VCF）、vSphere Foundation（VVF）、vSphere Standard（VVS）、vSphere Essential Plus（VVEP）に統合されました。以前は特定のコンポーネントのみを購入していたお客様も、現在はより広範なバンドルを購入することになります。

大幅な価格上昇。 顧客からの報告によると、以前の構成や、どの新しいバンドルが最も近い代替品となるかによって異なりますが、コストは以前の8倍から15倍に跳ね上がっています。特に、72コアというライセンスの最低要件は、小規模な導入環境にとって大きな負担となっています。

パートナープログラムの縮小。 VMware Cloud Service Providerプログラムは、世界中で4,500社以上あった認定プロバイダーから、VCFを中心とした招待制の、はるかに小規模なプログラムへと縮小されました。これは、特に中小企業および中堅企業のお客様にとって、市場へのアクセス経路に影響を及ぼします。

ハイパースケーラー向けのライセンス変更。 2025年11月1日より、「Azure VMware Solution」または「AWS Elastic VMware Service」上でVMwareをご利用のお客様は、Broadcomから直接購入したポータブルなVCFサブスクリプションを自ら用意する必要があります。 ハイパースケーラー経由での従来のバンドルライセンスは、新規導入においては利用できなくなりました。

これらは予測ではありません。2026年初頭時点での事実です。合理的な顧客であれば、これに対してどう対応すべきかについて意見が分かれるでしょう。 大半の顧客は、現在、選択肢を検討しているところです。

なぜバックアップアーキテクチャが3年前よりも重要になっているのか

Broadcomが登場する前は、VMware用バックアップツールの選択は、主に技術的な判断でした。どの製品がvSphereスナップショットを最も適切に処理し、vCenterとシームレスに統合され、最も迅速に復旧できるか、といった点です。 アーキテクチャ上の問題、つまりバックアップがVMwareにどの程度密接に紐づいているか、他のハイパーバイザーでも動作するかといった点は重要でしたが、評価リストの最優先事項となることはめったにありませんでした。

現在、3つの要因が、これまでとは異なる評価を導いています。

VMwareと併せてライセンス供与されるバックアップは、VMwareの価格設定の動向を受け継ぐことになります。 VCFにバンドルされている、あるいはVMware専用製品として販売されているバックアップツールは、Broadcomが今後どのような決定を下すかに左右されます。一方、vCenter APIを利用して動作する独立したバックアッププラットフォームは、その影響を受けません。

戦略的な柔軟性には、今や測定可能な経済的価値があります。今日VMwareを保護し、明日にはNutanixやAWSも保護できるバックアッププラットフォームは、組織に選択肢を提供します。 VMware上でのみ動作するバックアッププラットフォームは、Broadcomの将来の価格決定がどのようなものになろうとも、顧客をその決定に縛り付けてしまいます。

移行ツールはもはやオプションではありません。VMwareからワークロードを積極的に移行している顧客には、移行プラットフォームとしても機能するバックアップが必要です。同じバックアップデータを、別のハイパーバイザーやクラウドに復元できることが求められます。 当面はVMwareを使い続けるお客様にとっても、その選択肢を用意しておくことにはメリットがあります。

依然として重要な技術的基礎

ビジネス環境は変化しましたが、技術的な要件は変わりません。VMwareバックアッププラットフォームが依然として適切に処理しなければならない3つの基盤があります。 

ハイパーバイザーレベルのスナップショットにおけるVMスタン（応答停止）の回避

VMスタンとは、VMwareのスナップショット処理中に、ハイパーバイザーがファイルシステムを静止状態に保ち、スナップショットをキャプチャし、メモリ内の状態をディスクに書き込む間、仮想マシンが応答しなくなる期間のことです。 「VM stun」の間、仮想マシンは事実上非アクティブ状態となります。I/Oトラフィックが多い場合、「VM stun」はプライマリサーバーのフェイルオーバーを引き起こすほど長く続く可能性があります。つまり、本来はダウンタイムを防ぐはずの保護メカニズム自体が、かえってダウンタイムを引き起こしてしまうのです。

スナップショットが完了した後、バッファログが「VM stun」中に発生した変更をキャプチャし、それらの変更を仮想マシンに適用し直す必要があります。 これもまた、時間を要する操作です。VMの規模が大きくなるにつれ（現在では数テラバイト級のvDiskが一般的です）、クワイエッセンス期間とバッファログの管理もそれに伴って増加しています。従来のVADPアプローチは、こうしたトレードオフを率直に認めてはいますが、解決には至っていません。 

これに対するアーキテクチャ上の代替案として、ハイパーバイザー層ではなく基盤となるストレージ層でストレージレベルのスナップショットを取得する方法があります。これにより、細粒度の更新のみをキャプチャし、再コミットの手順が不要になります。Nutanix-on-ESXi環境では、AHVおよびESXi VMの両方で機能するNutanixネイティブのスナップショットAPIを通じて、これが実現されます。 バックアップ性能はVMのサイズに影響されず、本番VMのダウンタイムも発生せず、バッファログのオーバーヘッドもありません。

単なるVMレベルのバックアップではなく、アプリケーションを意識した保護

VMレベルのバックアップは必要ですが、それだけでは不十分です。 VM内で実行されている重要なアプリケーション（SQL Server、Oracle、Exchange、SAP）には、アプリケーション独自の整合性メカニズム（Windows上のVSSライター、Linux上のアプリケーションクワイエスフック）と連携する、アプリケーション認識型のバックアップが必要です。 これがなければ、バックアップファイルは作成されても、トランザクションの一貫性は保証されません。

設定不要の自動アプリケーション検出により、スケーラビリティが実現されます。バックアッププラットフォームは、どのVMでどのアプリケーションが実行されているかを識別し、適切な保護を自動的に適用すべきであり、管理者がVMごとにマッピングを指定する必要はありません。 

vCenterとの統合およびシステムへの影響ゼロの導入

バックアップ操作は、vCenter APIを通じて統合され、既存の権限、ロール、およびリソースプール構造を継承する必要があります。バックアッププラットフォームは、VMwareクラスタ上でソフトウェアのみで動作する必要があります。 追加のWindows Serverライセンスも、追加のデータベースライセンスも、迅速な復旧のための別途のインフラも不要です。導入に大規模な新規インフラを必要とするVMwareバックアップは、Broadcomの変更によってすでに圧迫されているコストをさらに増大させることになります。 

顧客との会話で見られる3つのシナリオ

2026年にVMwareバックアップを評価している組織のほとんどは、以下の3つのシナリオのいずれかに該当します。契約期間中に顧客の状況が変化する可能性があるため、選択に値するバックアッププラットフォームはこれら3つすべてに対応している必要があります。 

VMware専用のバックアップ製品は、シナリオ1にはうまく対応できますが、シナリオ2では苦戦し、シナリオ3では顧客の利益に反する結果となります。 ハイパーバイザーに依存しないバックアッププラットフォームは、同一の管理プレーンを通じてこれら3つのシナリオすべてに対応します。

Broadcom買収後の注目点

今後5年間にわたって通用するVMwareバックアップオプションと、Broadcom買収前の市場向けに最適化されたオプションとを区別する6つの基準があります。 

VMwareのライセンスへの依存がないこと。バックアップベンダーのビジネスモデルやロードマップは、Broadcomの決定に左右されてはなりません。バンドルへの組み込みや共同マーケティングは問題ありませんが、技術的または商業的な依存は許容されません。

ハイパーバイザーに依存しないアーキテクチャ。 VMware ESXi、Nutanix AHV、Hyper-V、および主要なパブリッククラウドに対するネイティブサポート。同一のバックアップデータを用いたハイパーバイザー間の移行は、単発のサービス契約ではなく、文書化され、サポート対象となっている機能であるべきです。

VMの停止を回避するためのストレージレベルのスナップショット。 ハイパーバイザーレベルのVADPスナップショットは信頼性が高いものの、機能には限界があります。基盤となるデータプラットフォーム（Nutanix、Pure、NetApp）とのストレージレベルでの統合により、大規模または高I/OのVMに対しても、システムへの影響を伴わない保護を実現します。

追加ライセンスを必要としない、ソフトウェアのみの導入。 追加のWindows Serverライセンス、SQL Serverライセンス、またはバックアップ専用のインフラストラクチャを必要とするバックアップは、すでに逼迫している予算にさらなるコストを課すことになります。既存のインフラストラクチャ上で動作する純粋なソフトウェアが、基本となるべきです。

アプリケーション認識型のバックアップおよびリカバリ。VM内で実行されているSQL Server、Oracle、Exchange、SAP、その他のエンタープライズアプリケーションの自動検出。 アプリケーション一貫性のあるバックアップ。ファイル、アプリケーション、またはVMレベルでのきめ細かな復旧が可能です。

ハイパーバイザーを横断したランサムウェア対策。WORM対応のバックアップストレージ、エアギャップ化されたバックアップコピー、バックアップ間の異常検知、セキュリティツールとのWebhook連携。ランサムウェアはハイパーバイザーの境界を無視します。 バックアップ対策も同様に、その境界を無視すべきではありません。

Broadcom買収後のVMwareバックアップに関するよくある質問

Broadcomによる変更を理由に、VMwareから移行すべきでしょうか？

それは組織としての決定事項であり、バックアップに関する決定事項ではありません。 正しい答えは、既存のワークロードへの投資、チームの専門知識、アプリケーションの依存関係、そして組織が実際に直面している価格上昇の程度によって異なります。バックアップアーキテクチャが提供すべきなのは、VMwareのライセンスに依存せず、もしVMwareからの移行を決定した場合にもそれをサポートできることで、その判断を後回しにできる選択肢です。バックアップの決定によって、VMwareに縛られたり、逆にVMwareから締め出されたりしてはなりません。 

「ESXから非ESXクラスターへの移行」とは、実際にはどのような意味でしょうか？

VMware ESXiクラスターから取得したバックアップデータを使用して、同じワークロードを別のハイパーバイザー（最も一般的なのはNutanix AHVですが、パブリッククラウドへの移行も含まれます）に復元することです。 バックアッププラットフォームが、フォーマット変換、構成の変換、および復旧のオーケストレーションを処理します。適切に実施されれば、移行後もアプリケーションの一貫性が維持された状態で、新しいハイパーバイザー上でワークロードが起動します。これは、クロスクラウドDRをサポートするメカニズムを、恒久的な移行向けに転用したものです。 

VMwareを使い続ける場合、Broadcomの動向によって、バックアップ選びの基準は実際に変わるのでしょうか？

はい、変わります。バックアップは数年単位の長期的な取り組みであるため、今日の適切な選択は、Broadcomの今後の動向にかかわらず、今後5年間にわたって有効であり続けるべきだからです。 当面の間、VMwareを使い続ける予定であっても、VMwareの事業展開とは独立してバックアップを選択することで、データ保護予算がVMwareの価格設定の影響を受けるのを防ぐことができます。 オプションには、たとえそのオプションを行使しなくても、オプション価値があります。

バックアップを移行ソースとして使用する場合、VMwareからNutanixへの移行にはどのくらいの時間がかかりますか？

個々のワークロードの技術的な移行には、通常、数日ではなく数時間しかかかりません。 バックアップをNutanixクラスターに復元し、ワークロードの検証を行った後、DNSとトラフィックを切り替えます。組織全体の移行は通常、バックアップおよび復元メカニズムそのものではなく、アプリケーション間の依存関係、テスト、およびチームの対応能力によって制約を受けます。 多くの組織では、アプリケーションごと、あるいは事業部門ごとに、12～36か月の期間をかけてこれらの移行を実施しています。

どこから始めるか

VMwareのデータ保護を見直している場合、最も有益な取り組みは、自組織が以下の3つのシナリオのうちどれに該当するかを正直に特定することです。 顧客との会話では、この明確さが欠けていることがよくありますが、その一因として、答えが1年の間に変化することが挙げられます。どのシナリオに該当するかが分かれば、バックアップ要件も具体化されます。弊社では、その検討プロセスを喜んでサポートいたします。 担当のアカウントチームにご相談いただくか、hycu.com/trialから始めてみてください。