VMDK Recovery guide
How to Recover a Deleted VMDK File
Last updated: October 11, 2026
This guide covers a deleted or missing VMDK container on supported non-VMFS host storage. A VMDK container is the virtual disk file set: it may include a descriptor, one or more data extents, and related snapshot components.
Stop using the affected physical disk first. Scan its host file system, assess the available VMDK candidates, and preview supported guest files before export when Mount as Disk is available for the scan result in the current build. Export the available VMDK components to a separate healthy physical device and verify the recovered set before you rely on it.
Start with the storage layer. Continue here only when the VMDK container is missing from supported non-VMFS host storage. A VMDK deleted from a VMFS datastore requires VMFS Recovery.
Important: Do not create a replacement VMDK, start the affected virtual machine, initialize or format the source, or save recovered files back to the same physical disk. New writes may overwrite the missing container or its related components.
Quick Answer: Recover the VMDK Container Without Writing to Its Source
If a VMDK container was deleted from supported non-VMFS host storage, stop activity on the affected physical disk and scan its host file system or a verified image. When the scan result and current build permit Mount as Disk, add the found VMDK to the disk list without saving it, open it as a disk in the program, and preview supported guest files. This option may not work for every candidate. Recovering the VMDK container requires licensed export to a separate healthy physical device; reopening the exported set provides another verification route.
| You need | Why it matters |
|---|---|
| Access to the source or a verified image | The scan needs the storage that held the missing container, not only an old path or filename. |
| Available source evidence | Names, locations, sizes, dates, and related components help distinguish a candidate from a verified result. |
| A separate healthy physical device | Recovered data must not overwrite evidence on the affected disk. Another partition on that disk is not separate. |
Results depend on what remains readable. Recovery may return an incomplete component set. It does not guarantee a complete, usable, or bootable virtual machine.
Choose the Correct Storage Layer Before You Scan
Use one routing decision before starting. Continue on this page only for a deleted or missing VMDK container on supported non-VMFS host storage.
| What you can observe | Action | Correct route |
|---|---|---|
| The VMDK container is missing from supported non-VMFS host storage | Continue | Use the source-safe workflow below. |
| The VMDK exists, but guest files inside it are missing | Reroute | Recover files from the available VMDK extent. |
| Snapshot or delta components are available | Reroute | Use VMDK Snapshot Recovery. |
| An ESXi SEsparse snapshot redo log is involved | Reroute | Use SEsparse VMDK Recovery. A hosted split VMDK uses numbered extents and is a different layout. |
| The descriptor is missing or unusable | Reroute | Use Recover VMDK Without Descriptor. |
| The VMDK was deleted from a VMFS datastore | Reroute | Use VMFS Recovery. |
| The goal is to restore or boot a complete virtual machine | Reroute | Use the complete-VM restoration guide. |
| The request requires editing a descriptor, CID, header, or source file | Stop | Preserve the source and work only from verified copies with specialist review. |
Protect the Source and Prepare Before Recovery
The source may be a local disk, external drive, disk image, network-accessible file set, or VMware host storage. The same rule applies in every case: keep the original state unchanged until the required data is safe elsewhere.
- Stop writes. Pause the affected VM, downloads, synchronization, cleanup, installation, snapshot changes, and any task that may use the source.
- Prepare the destination. Use a separate healthy physical device with enough space for the recovered VMDK set and the guest files you may later export.
- Record the evidence. Note the source device, path, available names, sizes, dates, and neighboring VMDK components without renaming or repairing them.
- Check the route. Return to the matrix if the source is VMFS, the container still exists, a specific component is missing, or the goal is complete-VM restoration.
The Most Important Recovery Tip: Do Not Write to the Affected Physical Disk
Stop the affected virtual machine if it is still using the source. Do not create a new disk with the same name, restore a snapshot over the source, consolidate snapshots, or attach the source to a workflow that may modify it.
Do not install the recovery program on the affected physical disk. Another partition on that disk is not a separate recovery destination.
Do not write to the source: a replacement VMDK, VM start, snapshot operation, format, or repair can overwrite file-system records and disk components that the scan needs.
Check the Host Storage
Confirm that the physical device or image is detected consistently. For local and external disks, check the model, capacity, serial number where the device reports one, connection, enclosure, and power once. Repeated disconnects, changing capacity, clicking, severe slowdown with read errors, or overheating are reasons to stop.
Software recovery is appropriate for a stable source with a logical loss. It is not a repair for failing hardware.
Decide Whether to Work from an Image
A verified sector image lets you scan a copy instead of repeatedly reading the original storage. Consider imaging when the VMDK is important, the host file system is damaged, several recovery attempts may be needed, or the original disk should be preserved for review.
Store the image on a healthy physical device with enough free space. If the source is unstable or physically failing, stop instead of running a long software scan or DIY imaging pass.
Common Mistakes and Safe Corrections
| Mistake | Safe correction |
|---|---|
| Continuing to use the source | Stop activity and preserve the current state before scanning. |
| Exporting to another partition on the affected disk | Choose a separate healthy physical device. |
| Scanning the wrong storage layer | Use the routing matrix before starting the scan. |
| Separating or renaming related components | Keep available files together and preserve names and directory relationships. |
| Trusting a recovered filename as proof | Compare evidence, reopen the set, and preview representative guest files. |
| Expecting VMDK Recovery to find a file the ESXi host no longer exposes | Use VMFS Recovery for sector-level datastore recovery when a required VMDK file is no longer exposed. |
| Editing descriptors or headers on the source | Stop and preserve the original; attempt any approved repair only on verified copies. |
Recover a Deleted or Missing VMDK Container Step by Step
These eight actions cover the owned non-VMFS container-recovery case. Keep the numbering continuous and leave this workflow as soon as an observation points to a different route.
1. Confirm the Scenario and Destination
Confirm that the VMDK container is missing from supported non-VMFS host storage and that a separate healthy physical device is ready.
Check: record the source and destination devices, including their serial numbers where each device reports one. Reroute if: the source is VMFS or the loss is inside an available VMDK. Stop if: the destination is on the affected disk.
2. Start the Recovery Tool and Select the Source
Run the DiskInternals Recovery Engine from a healthy Windows drive. Select the affected physical source or a verified image without creating, formatting, or repairing anything on it.
Check: match the device model, capacity, recorded location, and serial number where the device reports one. Stop if: the source is unstable or cannot be identified reliably.
3. Use Remote File Access Only When the VMDK Is Still Accessible
When remote access applies, follow this order: VMDK Recovery → SFTP → ESXi host → accessible VMDK files → selected VMDK opened as a disk in the program → guest file system. VMware vSphere is the platform; ESXi is the hypervisor on the host.
Check: confirm that the required VMDK files are visible through the host. Reroute if: the datastore no longer exposes the deleted file; use VMFS Recovery for datastore-level deletion.
4. Confirm the SFTP Boundary
VMDK Recovery opens files that the ESXi host exposes through SFTP, but it does not parse VMFS or scan deleted datastore space. VMFS Recovery can use its ESXi connection for sector-level VMFS recovery.
Check: decide whether this is recovery from an exposed VMDK file or a datastore-level deletion. Reroute if: recovery requires deleted VMFS records.
5. Select the Applicable Scan Method and Start the Scan
Choose the scan method that the current product build offers for the verified host file system and type of loss. Start the scan without writing to the source.
Check: confirm that the selected source and scan target match the preflight record. Stop if: the expected source or applicable scan option is unavailable.
6. Assess the VMDK Candidates and Preview When Available
Compare available locations, names, sizes, dates, and relationships to descriptors, extents, snapshot/delta components including SEsparse redo logs, parent files, and any separate hosted split-disk segments. Do not manually reconstruct or repair the set.
When the scan result and current build permit Mount as Disk, add the found VMDK to the disk list without saving it, open it as a disk in the program, and preview supported guest files. This option may not work for every candidate; record unavailable previews and use post-export verification as another route.
Check: mark the strongest candidate and any uncertain relationships. Reroute if: the evidence points to a missing-metadata or component-specific route.
7. Export the Available VMDK Set Safely
Use the licensed export path to save the selected VMDK and its available related components to the separate healthy physical device. Preserve their names and directory relationships.
Check: verify the destination device before export. Stop if: it is the affected disk or there is not enough space.
8. Reopen the Recovered Set and Preview Guest Files
Open the recovered disk or set in VMDK Recovery. Browse the guest file system and preview representative documents, images, archives, databases, or project files from important folders.
Check: record successful previews and unavailable results. Stop or reroute if: the set cannot be opened or important content is unavailable.
Evaluation and export are separate: the free evaluation can scan and preview supported files. Saving recovered results requires a license, and every export must go to a separate healthy physical device.
Verify the Recovered VMDK Set and Representative Guest Files
A recovered filename is a candidate, not proof of usable data. Use this checklist before choosing another route or relying on the result.
| Check | Pass | Needs review |
|---|---|---|
| Destination | The recovered set is on a separate healthy physical device. | Any result was written to the affected disk. |
| Available components | Related files remain together with preserved names and relationships. | Files were renamed, separated, or expected relationships are uncertain. |
| Evidence match | Location, names, sizes, dates, and relationships agree with the preflight record. | Only the extension or filename appears plausible. |
| Guest-file preview | Representative files from important folders can be previewed. | The set cannot be opened or important files are unavailable. |
| Recovery scope | The required data is accessible and unavailable results are documented. | The result depends on missing components or a different storage layer. |
When the scan result and current build permit Mount as Disk, a found VMDK can be added to the disk list without saving it, opened as a disk in the program, and used to preview supported guest files. This may not work for every candidate. Recovering the VMDK container requires licensed export to a separate healthy physical device; reopening that export provides another verification route.
Available VM configuration files can be recovered as individual files. They do not restore the complete VM configuration or guarantee that the VM will function on a different server. Previewing representative files does not prove that every guest file is intact or that the virtual machine is bootable. Review the VMDK Recovery product workflow after the checklist.
Frequently Asked Questions About Deleted VMDK Recovery
-
No. Another partition on the affected physical disk is not a separate destination. Export recovered results to a separate healthy physical device.
-
Compare the available location, name, size, date, and relationships to other components with the preflight record. Discovery does not prove usability. When Mount as Disk is available for the scan result in the current build, add the found VMDK to the disk list without saving it, open it, and preview supported guest files. This may not work for every candidate; verify guest files again after licensed export and reopening.
-
Yes. Preserve available components together with their names and directory relationships for assessment and verification. This does not guarantee that every dependency is present or usable.
-
For accessible files, use VMDK Recovery → SFTP → ESXi host → accessible VMDK files → selected VMDK opened as a disk in the program → guest file system. VMDK Recovery opens files exposed by the host but does not parse VMFS or scan deleted datastore space. VMFS Recovery handles sector-level VMFS recovery when a VMDK is no longer exposed.
-
The free evaluation can scan the host file system and preview supported files. When the scan result and current build permit Mount as Disk, add the found VMDK to the disk list without saving it, open it, and preview supported guest files. This may not work for every candidate. Saving the recovered VMDK container requires licensed export to a separate healthy physical destination; reopening that export provides another verification route. See the VMDK Recovery product overview.
-
Return to the storage-layer matrix for guest-file loss inside an available VMDK, direct VMFS deletion, missing descriptor metadata, snapshot, delta or SEsparse cases, manual repair requests, or complete-VM restoration.