仮想マシンのVHDX・VMDKを削除した時の復元|新規作成前の確認手順

削除したVHDX・VMDKの保存領域に空きが生じた仮想マシンデータ復旧のイメージ

Hyper-VやVMwareで使っていた仮想マシンを整理中に、VHDXやVMDKを削除すると、管理画面から仮想マシンが消えたり、起動時に仮想ディスクが見つからないと表示されたりします。
急いで同じ名前の仮想マシンやディスクを作れば戻るように思えますが、その新規作成が削除済みデータの領域へ書き込む原因になります。

最初に優先するのは、仮想マシンを作り直すことではありません。
対象のデータストアやドライブへの書き込みを止め、削除した時刻、ファイル名、保存場所、スナップショット、バックアップ、実行済み操作を記録することです。

この記事では、VHDX・VMDKを削除した時に、何を、なぜ、どの順番で確認するかを初心者向けに整理します。
仮想ディスク本体だけでなく、構成ファイルや差分ディスク、ゲストOS内のデータを分けて考え、元の保存先を変えないことを中心に進めます。

目次

VHDX・VMDKを削除したら新しい仮想マシンを作成しない

結論からいうと、必要なVHDXやVMDKを削除したと分かったら、同じホスト・同じデータストアで新しい仮想マシンを作成しません。
同名の仮想ディスクを空で作る、既存VMへ新しいディスクを追加する、テンプレートを展開するといった操作も止めます。

ファイルを削除しても、保存領域の内容が即座にすべて消えるとは限りません。
しかしOSやハイパーバイザーからは空き領域として再利用できる状態になり、その後のログ、更新、一時ファイル、新規ディスク作成によって上書きが進む可能性があります。

仮想ディスクは数十GBから数TBになることがあり、新規VMの作成や起動はまとまった書き込みを発生させます。
名前が同じかどうかではなく、物理的に同じデータストアへ書き込むかどうかで危険を判断してください。

  • 新しいVHDX・VMDKを作らない
  • 同じ場所へ空の仮想マシンを登録しない
  • チェックポイントやスナップショットを作成・削除・統合しない
  • 仮想ディスクの最適化、圧縮、変換、拡張を実行しない
  • 元データストアへ復元ソフトをインストールしない
  • 復元結果を元のドライブへ保存しない

仮想マシンの停止だけでは、ホストOSや別のVMによる書き込みが続く場合があります。
対象ストレージを安全に切り離せる構成なら、管理者が停止手順を確認し、影響範囲を記録したうえで読み書きを止めることが重要です。

最初の10分で止める処理と残す記録

元ドライブと別の復元先ドライブを分けて記録しながら調査するデータ復旧作業台

最初の10分では、復元を始めるより先に、追加書き込みを止めて事実を保存します。
担当者を一人に決め、ほかの利用者には仮想環境へログインせず、再起動や自動復旧を実行しないよう伝えてください。

  1. 対象VMを起動・再起動しない
  2. バックアップ、レプリケーション、チェックポイント整理、スナップショット統合を止める
  3. 削除操作を行った日時、ユーザー、画面、コマンドを記録する
  4. VHDX・VMDKの元の完全パス、ファイル名、概算容量を残す
  5. ホスト名、ハイパーバイザー、バージョン、データストア名を記録する
  6. 関連する構成ファイル、差分ディスク、ログの一覧を別の場所へ保存する
  7. 正常なバックアップとレプリカがあるか、問題のストレージを動かさず確認する

「削除」を押しただけなのか、仮想マシンの登録解除なのか、ストレージ上のファイル削除まで実行したのかで状況は変わります。
管理画面のタスク履歴、イベント、監査ログ、シェル履歴、バックアップ製品のジョブ履歴を確認し、操作の種類を決めつけないでください。

共有ストレージを複数人で管理している場合は、ほかの管理者や自動処理も止めます。
共有フォルダを誤削除した時の復元手順と同じく、本人だけが操作を止めても別の端末から書き込みが続けば保全になりません。

消えた対象を仮想ディスク・構成・差分へ分ける

復元対象は「仮想マシン一式」とまとめず、仮想ディスク本体、構成情報、差分ディスク、メモリ状態、ログに分けます。
どれが消え、どれが残っているかを整理すると、必要のない書き戻しや誤った結合を避けられます。

種類主な例役割と注意
仮想ディスク本体VHD、VHDX、VMDKゲストOSやデータを保存。最優先で保全する
差分ディスクAVHDX、delta VMDKスナップショット後の変更を保持。順序を変えない
構成ファイルVMCX、VMRS、VMX、NVRAMCPU、メモリ、接続先などを保持。再作成できる場合もある
状態・メモリ保存状態、サスペンド関連実行中状態の再開用。ディスク整合性と分けて考える
ログ・記録イベント、タスク、vmware.log削除時刻、パス、ディスク構成を確認する材料

構成ファイルだけが消え、VHDXやVMDK本体が残っている場合は、別の検証環境で既存ディスクとして接続できる可能性があります。
反対に、管理画面にVM名が残っていても、仮想ディスク本体が削除されていれば起動はできません。

差分ディスクがある構成では、親ディスクと子ディスクの関係が重要です。
単独で開く、名前を変える、手作業で結合する前に、元のパス、作成時刻、識別情報、チェーンの順序を記録してください。

Hyper-VとVMwareで確認場所を整理する

Hyper-VとVMwareでは名称や保存構成が異なりますが、確認の基本は同じです。
管理画面の表示だけで判断せず、ホストが参照していた実際の保存先と、残っている関連ファイルを読み取り中心で一覧化します。

Hyper-Vで確認するもの

Hyper-VではVHDX本体のほか、チェックポイントがあるとAVHDXが存在することがあります。
仮想マシンの設定保存先、仮想ハードディスクの保存先、既定値、CSVや共有ボリュームのパスを記録し、残存ファイルの日時と容量を控えます。

Hyper-VマネージャーからVMが消えていても、ディスクが残っている場合があります。
すぐにインポートや新規VMへの接続を行わず、まず元のVHDXとAVHDXを別の正常な保存先へ保全できるか確認します。

VMwareで確認するもの

VMwareではVMXなどの構成ファイル、VMDK記述子、実データを持つフラットファイル、スナップショット差分が分かれている場合があります。
小さなVMDKファイルだけを見て本体が空だと判断せず、同じフォルダの関連ファイル名、容量、日時を一覧にしてください。

データストアブラウザーで削除したのか、ホストOSのファイル操作で削除したのか、ストレージ側で削除したのかも記録します。
削除経路によってごみ箱の有無、ログ、復旧対象のファイルシステムが異なるためです。

ごみ箱・バックアップ・レプリカ・スナップショットの順を間違えない

最も安全なのは、削除済み領域を走査する前に、別の正常なコピーから必要データを取り戻せるか確認することです。
ただし、バックアップが存在するだけで安心せず、対象VM、取得日時、保持世代、復元先、暗号化情報まで確認します。

  1. 管理画面上の登録解除だけで、実ファイルが残っていないか確認する
  2. ホストOS、NAS、クラウド、データストアのごみ箱や保持領域を確認する
  3. バックアップ製品の成功ジョブと復元ポイントを確認する
  4. レプリカやセカンダリサイトの最終同期時刻を確認する
  5. ストレージスナップショットが削除前の世代を保持しているか確認する
  6. 仮想化側のスナップショットと差分ディスクの残存状態を確認する
  7. どのコピーも使えない場合に、元ストレージの解析を検討する

仮想化側のスナップショットは、独立したバックアップとは限りません。
親ディスクと同じデータストアにあり、親や差分の一部が消えれば、スナップショットだけでは起動できない場合があります。

バックアップの場所や世代が分からない時は、データ復旧前に確認したいバックアップと保存場所を参考に、外付け媒体、NAS、クラウド、別PC、バックアップソフトの順で記録を集めてください。

元データストアへ復元しない理由

復元先は、削除したVHDX・VMDKがあったデータストアとは別の正常なストレージにします。
元の場所へ保存すると、まだ回収していない削除領域を復元ファイル自身で上書きする可能性があるためです。

復元物を元と同じパスへ戻すと、どれが原本の残存データで、どれが新しく作ったファイルか分かりにくくなります。
調査用コピー、復元結果、検証済み成果物をフォルダと媒体で分け、日時と作業者を記録してください。

  • 原本ストレージ:書き込みを止め、必要ならセクター単位の複製元として保管
  • 調査用コピー:解析や復元ソフトを試す対象
  • 復元結果用ストレージ:見つかったVHDX・VMDKや抽出ファイルを保存
  • 検証環境:ネットワークから隔離してVMやゲストファイルを確認
  • 利用用ストレージ:検証済みデータだけを業務へ戻す先

容量不足を理由に元データストアへ戻すのは避けます。
仮想ディスク本体に加えて複製、復元結果、展開したゲストファイルの容量が必要になるため、作業前に十分な別媒体を用意してください。

復元ソフトやストレージ解析を試せる条件

復元ソフトを検討できるのは、物理障害の兆候がなく、対象ストレージへの書き込みを止め、別媒体へ結果を保存できる場合です。
本番ホストへソフトを追加せず、可能なら原本のセクター単位複製を作り、そのコピーを解析します。

削除ファイルを見つけても、ファイル名と容量だけでは正常と判断できません。
VHDX・VMDKのヘッダー、親子関係、内部パーティション、ゲストファイルシステム、アプリケーションデータの整合性を段階的に確認します。

データ消失には削除以外に、移動、登録解除、権限変更、データストアの未接続、ファイル名変更、スナップショット統合中の問題などがあります。
データ消失の原因を見極める考え方も参考に、削除と断定する前にイベントと保存先を照合してください。

SSD、薄型プロビジョニング、TRIMやUNMAPが関係する環境では、削除後の回収条件がHDDと異なります。
通電やストレージのバックグラウンド処理で状態が変わる可能性があるため、重要データなら試行を重ねず専門相談へ切り替えます。

AVHDX・差分VMDKが残る場合は単独で結合しない

ホストコンピューター上の仮想ディスクとスナップショット差分を層ごとに保全するイメージ

差分ディスクが残っている場合は、親ディスクとの関係を確認する前に、単独で名前変更、接続、結合をしません。
差分にはスナップショット作成後の変更だけが入り、親ディスクと正しい順序で組み合わせて初めて最新状態を再現できる場合があります。

親ディスクを削除した後に、同名の空ディスクを作ると、差分側が参照する識別情報と一致しません。
ファイル名だけを合わせても安全に戻るとは限らず、無理な付け替えやメタデータ編集で調査材料を失うことがあります。

  • 親・子候補のファイル名、完全パス、容量、更新日時を記録する
  • AVHDXやdelta VMDKを別媒体へそのまま複製する
  • ログや構成ファイルから元の接続順を確認する
  • 自動統合が始まる操作を避ける
  • 原本ではなくコピー上でチェーンを再現する
  • 最新状態だけでなく、重要データが存在した時点を決める

スナップショットが多いほど新しいとは限らず、途中の差分が欠けると後続を正しく適用できない場合があります。
「最新ファイルだけを残す」のではなく、関連候補を一式で保全してください。

共有ストレージ・NAS・RAID上の仮想マシンは機器構成も守る

VHDX・VMDKがNAS、SAN、RAID、クラスター共有ボリュームにあった場合は、ファイル削除とストレージ障害を分けて確認します。
異音、切断、RAID警告、I/Oエラーがあるなら、削除ファイルの走査より先に物理状態と構成保全を優先してください。

複数ホストが同じデータストアを使う構成では、一台を止めても別ホストからログやVMデータが書き込まれます。
クラスター、バックアップサーバー、監視、レプリケーション、ウイルス対策、インデックス作成など、書き込み元を一覧にして停止範囲を決めます。

RAIDの再構築、ドライブ交換、ファイルシステム修復を先に行うと、削除時点からさらに状態が変わります。
仮想マシン復元のためにストレージを直すのか、ストレージ全体からデータを救出するのか、目的を分けて判断してください。

保存先機器の動作回復と、必要な仮想ディスクの救出は同じ作業ではありません。
データ復旧と機器修理の違いを確認し、交換や初期化の前に必要データの扱いを相談します。

復元後は別環境でゲストOSとデータを検証する

復元できたVHDX・VMDKは、すぐ本番ホストへ戻さず、コピーを使って隔離した検証環境で確認します。
仮想ディスクが接続できること、ゲストOSが起動すること、必要なファイルが正しいことは別々の確認項目です。

  1. 復元ファイルの容量、日時、ハッシュ値を記録する
  2. コピーを作り、原本の復元物は変更せず保管する
  3. 可能なら読み取り専用でパーティションとファイル一覧を確認する
  4. 重要フォルダ、データベース、メール、業務アプリのデータを抽出する
  5. 起動検証が必要ならネットワークを隔離し、自動更新や同期を止める
  6. ゲストOSのファイルシステム、サービス、ログ、アプリ整合性を確認する
  7. 検証済みデータだけを新しい正常環境へ移す

起動できても、削除直前の書き込みが欠けたり、データベースやメールストアが不整合になったりする可能性があります。
代表ファイルを数個開くだけで完了にせず、業務上必要な期間、件数、更新日時、アプリ機能を確認してください。

ゲストOS内で暗号化を使っていた場合は、回復キー、証明書、パスワードも必要です。
仮想ディスクのバイト列を回収できても、暗号化情報がなければ内容を利用できないため、別端末や管理記録から鍵の有無を確認します。

自力作業を止めて専門相談へ切り替える基準

必要データが唯一の原本で、元ストレージの複製を作れない場合は、自力で何度も試さず相談へ切り替えます。
一回の操作で必ず悪化するとは限りませんが、試行履歴が増えるほど削除直後の状態から離れ、原因と結果を区別しにくくなります。

  • 仮想ディスクが業務サーバー、会計、顧客、設計、開発の唯一の原本である
  • VHDX・VMDKが数百GB以上で、別媒体へ複製できない
  • AVHDXや差分VMDKが複数あり、親子関係が分からない
  • SSD、SAN、RAID、共有ストレージ、暗号化が関係する
  • 削除後に新規VM作成、再起動、統合、復元の上書きを行った
  • ストレージに異音、切断、速度低下、I/Oエラー、RAID警告がある
  • バックアップはあるが復元テストに失敗する
  • ゲストOSは起動してもデータベースや重要ファイルが開けない

相談先には「仮想マシンを起動できるようにしたい」のか、「ゲスト内の特定データを回収したい」のかを伝えます。
起動復旧にこだわるより、必要ファイルやデータベースを抽出する方が安全で早い場合があります。

相談先の選び方や確認項目は、データ復旧業者の料金と特徴を比較した記事も参考にし、診断時の書き込み、元媒体の返却、復元先、キャンセル条件を事前に確認してください。

相談前にそろえる情報

相談前の情報が具体的だと、不要な起動や再現操作を減らせます。
分からない項目は推測で埋めず、「不明」としたうえで、画面、ログ、写真、構成資料をそのまま渡してください。

分類伝える内容
仮想化環境Hyper-V・VMware等の製品名、バージョン、ホストOS
対象VMVM名、用途、ゲストOS、必要データ、最終正常時刻
仮想ディスクファイル名、形式、容量、保存パス、固定・可変
差分チェックポイント数、スナップショット名、AVHDX・deltaの一覧
保存先HDD・SSD・NAS・SAN・RAID、ファイルシステム、空き容量
削除操作日時、画面・コマンド、実行者、削除後の操作
バックアップ製品、世代、最終成功日時、復元テスト結果
障害兆候異音、切断、警告、I/Oエラー、速度低下、停電

削除後に行った操作は、都合が悪く見えても省略しません。
新規VM作成、同名ファイル作成、再起動、復元ソフト、chkdsk、RAID再構築、スナップショット統合など、順番と回数が復元方法の判断材料になります。

復旧後は仮想マシンとゲストデータを別に保護する

復旧後は、仮想マシン全体のバックアップと、ゲストOS内の重要データのバックアップを分けて設計します。
VMイメージだけではアプリケーション整合性が取れない場合があり、ゲスト内のファイルバックアップだけでは短時間でVM全体を戻せないためです。

  • VM全体を別ストレージへ世代管理する
  • データベースやメールはアプリ対応のバックアップを取る
  • バックアップ先を本番データストアから分離する
  • レプリカとバックアップを同じものとして扱わない
  • チェックポイントを長期バックアップ代わりにしない
  • 復元テストでVM起動と重要データの利用を確認する
  • 削除権限、承認、操作ログ、保持期間を見直す
  • 暗号化キーと構成資料を別の安全な場所へ保管する

誤削除対策では、管理画面の確認ダイアログだけに頼りません。
本番データストアの削除権限を限定し、バックアップの成功通知と復元テストを定期的に確認する運用が重要です。

VHDX・VMDK削除後の復元でよくある質問

同じ名前の空のVHDXやVMDKを作ればVMを起動できますか?

空の仮想ディスクには元のゲストOSやデータがないため、同名にしても復元にはなりません。
さらに同じデータストアへ作成すると削除領域を上書きする可能性があるので、作成せず元の保存先を保全してください。

VMの登録を削除しただけならVHDX・VMDKも消えていますか?

登録解除と実ファイル削除は別の操作ですが、製品、画面、選択肢によって扱いが異なります。
管理画面だけで決めず、元のデータストアに仮想ディスクと構成ファイルが残っているかを読み取り中心で確認します。

バックアップから元の場所へ直接復元してよいですか?

削除原因と必要世代を確認する前の上書き復元は避け、まず別の保存先へ復元して内容を検証します。
正しいVM・世代・データが確認できた後に、新しい正常な本番環境へ移行してください。

VHDX・VMDKが見つかれば完全に戻せますか?

ファイルが見つかっても、途中が上書きされている、差分チェーンが欠けている、内部ファイルシステムやアプリデータが不整合という場合があります。
容量や名前だけでなく、別環境でゲスト内の必要データを実際に検証する必要があります。

ホストをすぐ電源断した方がよいですか?

煙、焦げ臭さ、異常発熱など安全上の緊急性がある時を除き、突然の電源断が別VMやストレージへ影響する場合があります。
書き込み元と依存関係を確認し、管理者が公式手順で停止します。判断できない時は操作を増やさず相談してください。

まとめ|新規作成より先にデータストアと構成を守る

VHDX・VMDKを削除した時は、同じ場所へ新しい仮想マシンや空のディスクを作らず、対象データストアへの書き込みを止めます。
削除時刻、元のパス、容量、構成ファイル、差分ディスク、バックアップ、削除後の操作を記録してください。

安全な確認順は、実ファイルの残存、ごみ箱や保持領域、バックアップ、レプリカ、ストレージスナップショット、差分チェーン、元ストレージ解析です。
復元結果は別媒体へ保存し、原本、調査用コピー、復元物、検証環境を分けます。

仮想ディスクが見つかっても、ゲストOS、ファイルシステム、データベース、暗号化、アプリケーションの確認が必要です。
唯一の原本、複雑な差分、SSD・RAID・共有ストレージ、物理障害が関係する場合は、試行を重ねず状態を保ったまま専門相談へ切り替えてください。

目次