VMware・Hyper-Vなど仮想基盤障害時のデータ復旧判断フロー

本当に信頼できるデータ
復旧業者3選をチェック

2026年10月、IDCフロンティアが提供するクラウドサービスでランサムウェア攻撃による障害が発生し、495の企業・自治体が影響を受けました。同社は仮想サーバーの停止・暗号化が発生したことを公表し、代替環境への移行やバックアップデータの取り出しなどの復旧支援を進めています。

この事例からも分かるように、仮想基盤の障害では、1台のサーバーの問題が複数の業務システムに影響することがあります。なお、この事例で使用されていた仮想化製品をVMwareまたはHyper-Vと断定するものではありません。

VMware ESXiやMicrosoft Hyper-Vなどの仮想化環境で仮想マシンが起動しなくなった場合でも、保存されているデータまで失われたとは限りません。ホストサーバー、共有ストレージ、仮想ディスク、ゲストOSなど、障害が発生している箇所によって復旧方法は異なります。

一方、原因を確認しないまま仮想ディスクを初期化したり、スナップショットやチェックポイントを削除したりすると、復旧できる可能性があったデータを失うおそれがあります。

本記事では、法人の情報システム担当者やITインフラ管理者に向けて、VMware・Hyper-V環境の代表的な障害、初動対応、データ復旧の判断フロー、復旧業者への相談が必要なケースを解説します。

※仮想化製品の仕様や復旧方法は、バージョン、ストレージ構成、クラスタリングの有無などによって異なります。実際の復旧作業では、利用している製品の公式情報を確認し、必要に応じて保守事業者や専門業者と連携してください。

VMware・Hyper-Vなど仮想基盤で障害が発生したときの初動対応

仮想サーバーが起動しなくなった場合、最初に重要なのは、障害箇所を切り分けることです。

仮想化環境では、1台の物理サーバー上で複数の仮想マシンが稼働していたり、複数のホストが共有ストレージを利用していたりします。そのため、同じ「仮想マシンが起動しない」という症状でも、原因はさまざまです。

復旧作業を始める前に、まずは現在の状態を把握しましょう。

まず確認したい5つの項目

仮想基盤の障害では、次の5項目を確認すると、問題が発生している範囲を整理しやすくなります。

確認項目	確認内容
① 障害の発生範囲	特定の仮想マシンだけか、複数の仮想マシンが同時に停止しているか
② ホストの状態	ESXiホストやHyper-Vホストが正常に稼働しているか
③ ストレージの状態	データストア、CSV、NAS、SANなどを正常に認識できているか
④ 仮想ディスクの状態	VMDK・VHDXなどのファイルや関連する構成情報が残っているか
⑤ バックアップの状態	正常なバックアップがあり、安全に復元できるか

例えば、複数の仮想マシンが同時に停止した場合は、個別のゲストOSよりも、ホストや共有ストレージ、仮想化基盤の管理機能に問題が発生している可能性があります。

一方、特定の仮想マシンだけが起動しない場合は、その仮想マシンの設定、仮想ディスク、ゲストOSなどを確認します。

ただし、症状だけで原因を確定することはできません。複数の要因が重なっている可能性も考慮しましょう。

障害発生直後に避けたい操作

仮想基盤の障害では、復旧を急いで行った操作がデータの状態を悪化させる場合があります。

特に、原因が分からない段階では、次のような操作に注意が必要です。

• エラーの原因を確認せず、ホストや仮想マシンの再起動を繰り返す
• 認識されないデータストアやボリュームを初期化する
• 既存の仮想ディスクに新しいデータを書き込む
• VMDK・VHDXファイルを不用意に移動・削除する
• スナップショットやチェックポイントの構成を確認せず、削除・統合する
• RAID構成を確認せずにリビルドを実行する
• 障害のあるストレージに対して、繰り返し修復処理を実行する
• ランサムウェア感染が疑われる環境にバックアップを直接接続する

これらの操作が常に禁止されるわけではありません。正常性や構成を確認したうえで、適切な手順に沿って実施する必要があるという意味です。

特にストレージの物理障害や仮想ディスクの破損が疑われる場合は、既存データへの書き込みを伴う操作を避け、必要なデータを保全することを優先しましょう。

障害状況を記録し、復旧前の状態を保全する

復旧方法を検討するためには、障害発生時の情報が重要になります。

可能な範囲で次の内容を記録してください。

• 障害を発見した日時
• 直前に実施した設定変更や更新作業
• エラーメッセージやイベントログ
• ホスト・仮想マシン・ストレージの構成
• 仮想ディスクの保存場所とファイル名
• スナップショットやチェックポイントの有無
• バックアップの取得日時と保存先
• 障害発生後に実施した操作

これらは、社内で原因を調査する際だけでなく、保守会社やデータ復旧業者へ相談する際にも役立ちます。

仮想化基盤全体に障害が発生している場合は、複数の機器を含めた復旧判断が必要になるため、以下の記事も参考にしてください。

サーバー・NAS・PC混在時のデータ復旧判断フローを見る

VMware・Hyper-V障害の原因を切り分けるデータ復旧判断フロー

VMwareやHyper-Vの仮想マシンが起動しない場合、障害箇所によって必要な対応が異なります。

重要なのは、仮想マシンそのものの問題なのか、仮想マシンを動かしている基盤側の問題なのかを切り分けることです。

最初に「ホスト・ストレージ・仮想ディスク・OS」のどこに障害があるかを確認する

代表的な症状と、主に確認したい箇所を整理しました。

障害状況	主な確認箇所	復旧の方向性
複数の仮想マシンが起動しない	ホスト、共有ストレージ、管理基盤	基盤側の障害を優先して調査する
特定の仮想マシンだけ起動しない	VM設定、仮想ディスク、ゲストOS	個別の仮想マシンの構成・データを確認する
データストアが認識されない	ストレージ接続、物理ディスク、ファイルシステム	書き込み操作を避けてストレージの状態を調査する
VMDK・VHDXが破損している	仮想ディスク、関連ファイル、差分ディスク	バックアップ復元や専門的なデータ復旧を検討する
スナップショット・チェックポイントでエラーが出る	差分ディスク、親子関係、空き容量	構成を保全し、整合性を確認する
ランサムウェア感染が疑われる	管理基盤、ホスト、仮想マシン、バックアップ	隔離と証拠保全を優先し、安全な環境で復旧する

例えば、ESXiホストに問題があっても、仮想ディスクが正常な外部ストレージに保存されていれば、別の正常な環境からデータを利用できる場合があります。

一方、共有ストレージのファイルシステム自体が破損している場合は、仮想マシン単体の設定変更では解決しない可能性があります。

仮想基盤のデータ復旧判断フロー

障害が発生した場合は、以下の順序で確認すると復旧方針を整理しやすくなります。

判断段階	確認すること	対応方針
STEP1	ランサムウェアや不正アクセスの疑いがあるか	疑いがある場合は隔離・証拠保全・セキュリティ調査を優先する
STEP2	障害が特定のVMだけか、複数のVMに及んでいるか	個別VMの問題と基盤全体の問題を切り分ける
STEP3	ホストやストレージが正常に稼働しているか	異常があれば基盤側の調査・保全を優先する
STEP4	仮想ディスクや関連ファイルが残っているか	データの残存状況と整合性を確認する
STEP5	正常で利用可能なバックアップが存在するか	利用可能な場合は安全な別環境で復元を検討する
STEP6	バックアップ復元が難しいか	原本を保全し、専門業者による診断・復旧を検討する
STEP7	復旧データとシステムの正常性を確認できたか	業務への影響を踏まえて段階的に再開する

このフローは、障害の原因を確定するものではありません。実際には複数の工程を並行して進めたり、専門家の判断によって対応順序を変更したりする場合があります。

バックアップが利用できる場合でも、復元先の安全性やデータの整合性を確認することが重要です。

また、業務システムごとに復旧の優先順位を決めておくと、復旧作業を進めやすくなります。

復旧したいデータの優先順位を決めるチェックシートを見る

VMware環境で発生する代表的な障害と復旧方法

VMware ESXi・vSphere環境では、ホスト、データストア、VMDKファイル、スナップショットなど、複数の要素が仮想マシンの動作に関係しています。

ここでは、代表的な障害とデータ復旧を考える際のポイントを整理します。

ESXiホストが起動しない・応答しない場合

ESXiホストが起動しない、または管理画面から応答しない場合は、物理サーバーの故障、OSの問題、ネットワーク障害、ストレージ接続障害などが考えられます。

まず、ホストのハードウェア状態、管理ネットワーク、ストレージの認識状況などを確認します。

また、vCenter Serverからホストが切断されている場合でも、必ずしもホスト上の仮想マシンが停止しているとは限りません。

管理画面で確認できないことと、仮想マシン自体が利用できないことを区別して判断する必要があります。

ホストの障害が原因であっても、仮想ディスクが正常な共有ストレージなどに残っていれば、別の正常なホストから仮想マシンを復旧できる場合があります。

ただし、別のホストへ移行する際は、仮想ハードウェアの互換性、ネットワーク構成、ストレージへのアクセス権限などの確認が必要です。

VMFSデータストアが認識されない場合

VMFSは、VMware ESXi環境で利用される仮想マシン向けのファイルシステムです。

データストアが認識されない場合は、ストレージの接続障害、LUNの認識不良、物理ディスクの障害、VMFSの破損などが考えられます。

確認したい項目には、以下のようなものがあります。

• ストレージ装置自体が正常に稼働しているか
• ESXiホストから対象のストレージを認識できているか
• 接続経路やストレージネットワークに障害がないか
• データストアの状態に関するエラーが記録されていないか
• 複数のホストで同じ障害が発生しているか

データストアが認識されないからといって、保存されている仮想マシンのデータが消失したとは限りません。

一方で、原因が分からないままデータストアを再作成したり、フォーマットしたりすると、残存データの復旧が難しくなるおそれがあります。

物理ストレージの故障が疑われる場合は、ストレージベンダーやデータ復旧専門業者への相談を検討しましょう。

VMDKファイルが破損・消失した場合

VMDKは、VMware環境で仮想ディスクを扱う際に使用されるファイル形式です。

VMDKファイルが破損したり、必要な関連ファイルが失われたりすると、仮想マシンが起動しない、仮想ディスクを認識できないなどの障害が発生する場合があります。

VMDKに関係するファイルには、仮想ディスクの構成情報や実際のデータを保持するファイル、スナップショットに伴う差分ディスクなどがあります。

そのため、特定のVMDKファイルだけが残っていても、仮想ディスク全体を正常に読み取れるとは限りません。

特にスナップショットを使用している場合は、親ディスクと差分ディスクの関係を保つことが重要です。

原因が不明な状態では、関連ファイルを削除したり、上書きしたりせず、可能な範囲で構成情報を保全しましょう。

正常なバックアップがある場合は、別環境への復元を検討します。バックアップがない場合は、残存する仮想ディスクやストレージの状態を専門業者に確認してもらうことも選択肢になります。

スナップショットが削除・統合できない場合

VMwareのスナップショットは、仮想マシンの特定時点の状態を保持するための機能です。

スナップショット取得後の変更内容は差分ディスクなどに保持されるため、関連するファイルの整合性が重要になります。

スナップショットの削除や統合に失敗する原因には、以下のようなものがあります。

• データストアの空き容量不足
• ストレージ接続の不具合
• ディスクのI/Oエラー
• バックアップソフトなどによるファイルロック
• 差分ディスクや親ディスクの関係不整合

Broadcomのサポート情報でも、スナップショット統合時のタイムアウトやI/Oエラーについて、基盤となるストレージの状態を確認することが案内されています。

統合処理が失敗した場合は、何度も処理を実行するのではなく、データストアの状態やエラーログを確認しましょう。

また、スナップショットは独立したバックアップの代わりになるものではありません。元のディスクやストレージに障害が発生すると、スナップショットも利用できなくなる場合があります。

参考：Broadcom「Snapshot Consolidation Fails With Error "Timeout"」

Hyper-V環境で発生する代表的な障害と復旧方法

Microsoft Hyper-V環境でも、仮想マシンの構成情報、仮想ディスク、チェックポイント、ホストや共有ストレージなどに障害が発生する場合があります。

VMwareと共通する考え方もありますが、使用するファイル形式や管理機能が異なるため、Hyper-V環境に適した確認が必要です。

Hyper-Vの仮想マシンが起動しない場合

Hyper-Vの仮想マシンが起動しない場合は、ホストの状態、仮想マシンの設定、仮想ディスクの接続、保存先へのアクセス権限などを確認します。

例えば、仮想ディスクの保存場所が変更されていたり、必要なファイルにアクセスできなくなっていたりすると、仮想マシンの起動に失敗することがあります。

また、仮想ディスクが正常でも、ゲストOSの起動に必要なファイルが破損している場合があります。

そのため、Hyper-Vホストが正常に動作していることと、ゲストOSが正常に起動することは分けて判断しましょう。

エラーが発生した場合は、イベントビューアーやHyper-Vの管理画面に表示された情報を記録し、原因を確認することが重要です。

VHDXファイルが破損した場合

VHDXは、Hyper-Vで利用される仮想ハードディスクのファイル形式です。

VHDXが破損すると、仮想マシンが起動しない、仮想ディスクを接続できない、保存されているファイルを読み取れないなどの問題が発生する場合があります。

確認したいのは、次のような項目です。

• VHDXファイルが保存先に存在するか
• ファイルサイズや保存場所に異常がないか
• チェックポイントに伴う差分ディスクが存在するか
• 保存先の物理ディスクや共有ストレージに障害がないか
• 正常なバックアップが存在するか

VHDXファイルが残っていても、内部のデータやゲストOSのファイルシステムが正常とは限りません。

また、原本に対する修復操作によってデータが変更される可能性があります。

重要なデータが保存されている場合は、必要な状態を保全したうえで、正常なバックアップからの復元や専門業者による調査を検討しましょう。

AVHDX・チェックポイントに問題がある場合

Hyper-Vでは、チェックポイントの利用に伴ってAVHDX形式の差分ディスクが作成される場合があります。

チェックポイントの削除処理では、通常、Hyper-Vが差分ディスクの内容を統合します。

しかし、チェックポイントの統合が失敗したり、親ディスクとの関係が壊れたりすると、仮想マシンが正常に起動できなくなる場合があります。

Microsoftは、チェックポイントの問題として、差分ディスクの親子関係の破損、空き容量不足、ファイルロックなどを挙げています。

特に注意したいのは、AVHDXファイルをエクスプローラーなどから直接削除しないことです。

AVHDXが不要に見える場合でも、現在の仮想マシンがそのファイルに依存している可能性があります。

チェックポイントの問題が発生した場合は、仮想ディスクの関係を確認し、Microsoftの公式手順や専門家の指示に沿って対応しましょう。

参考：Microsoft Learn「チェックポイントの使用」

参考：Microsoft Learn「Hyper-Vスナップショット、チェックポイント、差分ディスクのトラブルシューティング」

CSV・共有ストレージに障害が発生した場合

Hyper-Vのフェールオーバークラスター構成では、CSV（クラスター共有ボリューム）などの共有ストレージが利用される場合があります。

共有ストレージに障害が発生すると、複数の仮想マシンに影響する可能性があります。

この場合は、個別の仮想マシンだけでなく、次のような項目を確認します。

• クラスターノードの稼働状態
• 共有ボリュームの認識状況
• ストレージ接続やネットワークの状態
• 物理ディスクやストレージ装置のエラー
• フェールオーバーの動作状況
• バックアップからの復旧可否

共有ストレージの障害が疑われる場合、複数の仮想マシンを個別に再起動しても問題が解決しないことがあります。

原因が不明な状態でボリュームを初期化したり、ストレージ構成を変更したりすることは避けましょう。

仮想サーバーのデータを復旧する4つの方法

VMwareやHyper-Vの仮想サーバーで障害が発生した場合、データの残存状況やバックアップの有無によって復旧方法が異なります。

ここでは、代表的な4つの方法を紹介します。

① 正常なバックアップから復元する

正常なバックアップが残っている場合は、そこから仮想マシンや必要なデータを復元できる可能性があります。

バックアップには、仮想マシン全体を対象とするものや、ゲストOS内のファイル・データベースなどを対象とするものがあります。

復元前には、次の項目を確認しましょう。

• バックアップが正常に取得されているか
• 復元したい日時のデータが含まれているか
• 仮想マシンの構成情報が保存されているか
• 復元先の環境に互換性があるか
• データベースや業務アプリケーションの整合性を保てるか

重要な業務データを扱う場合は、可能な範囲で別環境に復元し、正常に利用できるか検証することが大切です。

② スナップショット・チェックポイントを利用する

障害発生前のスナップショットやチェックポイントが残っていれば、以前の状態へ戻せる場合があります。

ただし、スナップショットやチェックポイントは、バックアップと同じものではありません。

元の仮想ディスクや差分ディスクが破損している場合、以前の状態へ戻せない可能性があります。

また、状態を戻す操作によって、その時点以降に行われた変更が失われる場合があります。

復元の可否や影響範囲を確認せず、安易に実行しないよう注意が必要です。

③ 残存している仮想ディスクからデータを取り出す

仮想マシンが起動できなくても、VMDKやVHDXなどの仮想ディスクが正常に残っていれば、別の環境でデータを読み取れる場合があります。

例えば、ゲストOSの起動に問題がある一方で、仮想ディスク自体は正常な場合などです。

ただし、仮想ディスクに差分ファイルが存在する場合は、関連するファイルを含めた整合性確認が必要になります。

また、仮想ディスクを別環境に接続する際には、誤った書き込みによるデータ変更や、マルウェア感染の拡大に注意する必要があります。

重要なデータを扱う場合は、原本を保全し、必要に応じて複製したデータを使って作業することを検討しましょう。

④ データ復旧専門業者に調査・復旧を依頼する

バックアップからの復元が難しい場合や、仮想ディスク・データストアに破損が疑われる場合は、データ復旧専門業者への相談を検討します。

特に、以下のような状況では専門的な調査が必要になることがあります。

• VMFSなどのデータストアが破損している
• VMDK・VHDXファイルが消失・破損している
• スナップショットや差分ディスクの関係が壊れている
• RAID・NAS・SANなどのストレージに障害がある
• 複数の仮想マシンが同時に利用できない
• 正常なバックアップが存在しない

ただし、すべての仮想基盤障害でデータを復旧できるわけではありません。

依頼前に、対象機器や仮想ディスクの形式、障害状況、復旧可能性の確認方法などを相談しましょう。

仮想基盤障害ではどこまで自社で対応し、いつ専門業者に相談すべき？

VMware・Hyper-Vの障害が発生した場合、社内で対応できるケースと専門業者への相談が必要なケースを分けて考えることが重要です。

判断のポイントは、障害原因を把握できているか、正常なバックアップがあるか、復旧作業によってデータを失う危険がないかという点です。

社内での復旧を検討しやすいケース

例えば、次のような場合は、社内の情報システム担当者や保守会社による対応を検討しやすいといえます。

• 仮想マシンの設定不備が原因と確認できている
• ホストやストレージが正常に稼働している
• 正常なバックアップが存在する
• 別環境で復元テストを実施できる
• 復旧手順や作業責任者が明確になっている

ただし、これらの条件に該当していても、作業内容によってはデータ変更や業務停止のリスクがあります。

重要なシステムでは、作業前に必要なデータを保全し、影響範囲を確認しましょう。

専門業者への相談を優先したいケース

次のような場合は、無理に社内で復旧作業を進めるよりも、専門業者への相談を検討しましょう。

• ストレージやデータストアの物理・論理障害が疑われる
• VMDK・VHDXファイルが破損している
• 差分ディスクの構成が分からなくなっている
• 複数の仮想マシンが同時に利用できない
• バックアップが存在しない、または正常性を確認できない
• RAIDや共有ストレージの再構築が必要になる可能性がある
• ランサムウェアなどの不正アクセスが疑われる

なお、ランサムウェア被害が疑われる場合は、データ復旧だけでなく、証拠保全や原因調査、再感染防止への対応も必要です。

その場合は、セキュリティ専門会社やインシデント対応会社との連携も検討してください。

ランサムウェア被害時のデータ復旧初動について詳しく見る

仮想基盤に対応する復旧業者の確認ポイント

データ復旧業者を選ぶ際は、仮想化製品への対応だけでなく、ストレージの種類や障害内容、情報管理体制なども確認しましょう。

確認項目	確認したい内容
仮想化製品への対応	VMware ESXi・vSphere、Microsoft Hyper-Vなどの対応範囲
仮想ディスク形式	VMDK・VHDXなどのファイル形式に対応できるか
ストレージ対応	RAID・NAS・SAN・共有ストレージなどへの対応可否
障害内容	論理障害、物理障害、仮想ディスク破損、差分ディスクの不整合への対応
データ保全方法	原本の保全、複製データによる作業、作業記録の有無
情報管理体制	NDA、アクセス管理、媒体の保管・返却、再委託の有無
復旧結果の確認	復旧可能なファイルの一覧、データ確認方法、作業報告書の有無
費用・納期	初期診断費用、追加費用、緊急対応、納期の目安

特に法人の基幹システムや顧客情報を保存しているサーバーでは、復旧率や価格だけで業者を選ばないことが大切です。

機器や構成への対応実績、データの取り扱い、復旧結果の確認方法などを比較しましょう。

NAS・RAID・サーバー対応のデータ復旧会社を比較する

法人向けデータ復旧会社を条件別に比較する

問い合わせ時に必要な情報を整理したい場合は、以下のページも参考にしてください。

データ復旧業者への問い合わせテンプレートを見る

仮想基盤の障害から復旧した後に見直したい対策

仮想基盤の障害から復旧できた場合でも、同じ原因によって再び障害が発生する可能性があります。

業務システムを安定して運用するためには、バックアップ、監視、ストレージ管理、セキュリティ対策などを見直すことが重要です。

バックアップの保護と復旧テスト

仮想化環境では、複数の業務システムが同じホストやストレージに依存している場合があります。

そのため、障害が発生した際にどの程度の時間で業務を再開できるか、どの時点のデータまで戻せるかを事前に確認しておくことが重要です。

バックアップ設計では、次のような項目を整理しましょう。

• 仮想マシン全体のバックアップを取得できているか
• 必要なアプリケーションデータも整合性を保って復元できるか
• バックアップが本番環境から適切に分離されているか
• 定期的に復旧テストを実施しているか
• 復旧に必要なシステム構成情報が保存されているか
• RTO（目標復旧時間）とRPO（目標復旧時点）が業務要件に合っているか

バックアップが正常に取得されていても、実際に復元できるとは限りません。

仮想マシン単体だけでなく、データベースや業務アプリケーションを含めた復旧テストを実施することが大切です。

仮想基盤の監視と構成管理

仮想基盤では、ホスト、ストレージ、ネットワークなど複数の要素が連携して動作しています。

障害の早期発見と復旧時間の短縮を図るため、次のような管理を検討しましょう。

• ホストやストレージの稼働状況を監視する
• データストアの空き容量を定期的に確認する
• スナップショットやチェックポイントを長期間放置しない
• ストレージのI/Oエラーやハードウェア障害を監視する
• 仮想マシンとストレージの依存関係を記録する
• 仮想基盤の構成情報や変更履歴を管理する

特にスナップショットやチェックポイントが増加すると、容量やパフォーマンス、統合処理に影響する場合があります。

通常のバックアップとは役割を分け、適切に管理しましょう。

管理基盤への不正アクセス対策

近年は、仮想基盤を管理するシステム自体がサイバー攻撃の対象になるケースもあります。

2026年10月のIDCフロンティアの事例では、管理ポータルの認証システムに存在した脆弱性が悪用され、仮想化基盤の管理者権限が不正取得されたと報告されています。

こうしたリスクを考えると、仮想基盤の管理機能に対するセキュリティ対策も重要です。

• 管理者アカウントの利用範囲を制限する
• 多要素認証を導入する
• 管理ネットワークを業務ネットワークから適切に分離する
• 仮想化製品や関連ソフトウェアの脆弱性情報を確認する
• 不要な外部公開機能や管理アクセスを制限する
• 管理操作や認証ログを監視する
• バックアップ環境へのアクセス権限を分離する

クラウドサービスを利用している場合は、サービス提供者と利用企業の責任分担を確認し、障害発生時の連絡体制やバックアップの取得範囲も把握しておきましょう。

データ復旧後の再発防止チェックリストを見る

VMware・Hyper-Vのデータ復旧に関するよくある質問

VMwareの仮想マシンが起動しない場合、データは復旧できますか？

仮想マシンが起動しなくても、データが失われているとは限りません。

ホストやゲストOSの障害であれば、仮想ディスクが正常に残っている可能性があります。一方、仮想ディスクやストレージ自体が破損している場合は、データ復旧が難しくなることがあります。

まずは障害箇所と仮想ディスクの状態を確認しましょう。

VMDKファイルが壊れていても復旧できますか？

破損の範囲や関連ファイルの残存状況によって異なります。

正常なバックアップがある場合は復元を検討できます。バックアップがない場合でも、残存するデータを調査できる可能性はありますが、復旧が保証されるわけではありません。

重要なデータが含まれている場合は、原本を保全したうえで専門業者に相談しましょう。

ESXiホストが故障しても仮想マシンのデータは残っていますか？

仮想ディスクが正常な共有ストレージなどに保存されていれば、データが残っている可能性があります。

ただし、ホストの内蔵ディスクやストレージ自体に障害が発生している場合は、データにも影響が及んでいることがあります。

保存場所とストレージの状態を確認することが重要です。

スナップショットから必ず復旧できますか？

必ず復旧できるわけではありません。

スナップショットは元のディスクや関連する差分ディスクに依存するため、それらに障害があると利用できない場合があります。

また、以前の状態へ戻す操作によって、その後の変更内容が失われる可能性があります。

Hyper-VのVHDXファイルを別のサーバーで利用できますか？

仮想ディスクが正常で、復旧先の環境との互換性や必要な構成条件を満たしていれば、別の環境で利用できる場合があります。

ただし、チェックポイントに伴う差分ディスクが存在する場合や、ゲストOSの構成に依存する場合は、追加の確認が必要です。

重要なデータを扱う場合は、原本を保全し、必要に応じて複製を使って検証しましょう。

VMwareのデータストアが認識されない場合、初期化してもよいですか？

保存されているデータが必要な場合は、原因が分からない状態で初期化することを避けてください。

データストアが認識されない原因には、接続障害、ストレージの故障、ファイルシステムの問題などがあります。

初期化や再作成によって残存データに影響する可能性があるため、まずはストレージの状態を確認しましょう。

ランサムウェアで暗号化された仮想ディスクは復旧できますか？

正常なバックアップが存在する場合は、安全な環境で復元できる可能性があります。

一方、仮想ディスク自体が強固に暗号化され、復号鍵や正常なバックアップがない場合は、復旧が極めて困難なことがあります。

ランサムウェア被害では、データ復旧だけでなく、感染拡大防止や証拠保全、原因調査も重要です。

ランサムウェア被害時のデータ復旧初動について詳しく見る

まとめ｜仮想基盤障害では障害箇所の切り分けとデータ保全が重要

VMware・Hyper-Vなどの仮想化環境で障害が発生した場合、仮想マシンが起動しなくても、保存されているデータが失われたとは限りません。

重要なのは、ホスト、ストレージ、仮想ディスク、ゲストOSのどこに問題があるかを確認し、状況に適した復旧方法を選ぶことです。

特に、以下の3点を意識しましょう。

• 仮想マシンが起動しない原因を、ホスト・ストレージ・仮想ディスク・OSに分けて確認する
• 原因が不明な状態では、初期化・上書き・差分ディスクの削除などを安易に実行しない
• バックアップの正常性とデータの残存状況を確認し、必要に応じて専門業者に相談する

仮想基盤では、1つのストレージやホストの障害が複数の業務システムに影響する場合があります。

そのため、日頃からバックアップや構成情報を適切に管理し、障害発生時に安全な復旧方法を判断できる体制を整えておくことが重要です。

自社だけで復旧可能性を判断できない場合は、対象の仮想化製品、ストレージ構成、障害状況などを整理したうえで、対応できる専門業者に相談しましょう。

NAS・RAID・サーバー対応のデータ復旧会社を比較する

法人対応できるデータ復旧業者の選び方を見る

参考資料・情報確認日

本記事は、以下の公式情報を参考に作成しています。

• IDCフロンティア「【第7報】不正アクセスに関する調査結果および今後の対応について」（2026年10月27日）
• Broadcom「Snapshot Consolidation Fails With Error "Timeout"」
• Broadcom「Virtual machine disk consolidation fails with I/O error」
• Microsoft Learn「チェックポイントの使用」
• Microsoft Learn「Hyper-Vスナップショット、チェックポイント、差分ディスクのトラブルシューティング」

情報確認日：2026年10月28日

※本記事は、法人向けの仮想基盤障害に関する一般的なデータ復旧の判断方法を解説するものです。実際の作業では、利用している製品やバージョン、ストレージ構成、障害状況などに応じて、保守会社や専門業者と連携して判断してください。

• その復元をあきらめない！本当に信頼できるデータ復旧Navi
• 法人・官公庁向けデータ復旧ガイド
• 庁内NAS障害時の復旧・報告・再発防止フロー
• データ復旧を外部委託するときの確認ポイント
• 官公庁向けに確認すべきデータ復旧の証明書・報告書対応