VMDK Recovery guide
VMDK Snapshot Recovery
Last updated: October 11, 2026
VMDK snapshot recovery can help retrieve guest files from snapshot or delta components that are still available and readable. A VMDK represents a virtual disk. The guest file system is the file system stored inside it.
The safe sequence is to classify the available evidence, keep the source read-only, scan, preview representative files, validate the result, and export selected files to a separate healthy destination. The process does not repair a source chain or consolidate snapshots. Recovering a VMDK or files from inside it does not restore the complete VM configuration or prove that the VM can boot.
Short answer: Preserve every accessible descriptor, parent disk, child snapshot or delta, flat extent, and related component without renaming or moving it. An inconsistent but accessible set may be assessed through bounded virtual reconstruction inside DiskInternals Recovery Engine, while deleted, inaccessible, storage-level, or complete-VM cases require a different route.
Check the component-evidence matrix before selecting a source.
Delta VMDK Recovery: Preserve the Chain Before You Scan
A snapshot chain can contain several files with different roles. A dependency is a relationship in which a child snapshot or delta relies on a parent component for earlier disk content. Seeing one delta file does not prove that all of its dependencies are present.
Holds accessible descriptors, parent disks, child snapshots or deltas, flat extents, and SEsparse snapshot redo logs. Hosted split-disk extents are a separate layout.
Builds a read-only virtual disk view from the available evidence without rewriting the source chain.
Are scanned, previewed, validated, and exported to a separate healthy destination.
| Component or layer | Why it matters |
|---|---|
| Descriptor | Small metadata that describes a virtual disk and points to one or more extents. It is not the guest data. |
| Parent disk | Holds the earlier state on which a child snapshot or delta may depend. |
| Child snapshot or delta | Stores changes made after its parent state. The latest required guest data may be here. |
| Flat extent | Contains virtual disk data. Its name and size alone do not prove that the complete dependency set is available. |
| SEsparse snapshot redo log | Stores one snapshot's redo-log data in a single -sesparse.vmdk file and may depend on its parent disk and descriptor. |
| Hosted split-disk extent | Belongs to a separate numbered-extent layout; use the component-specific route before scanning. |
| Host storage and guest file system | Host storage holds the VMDK components. VMDK Recovery opens files exposed by ESXi but does not parse VMFS; VMFS Recovery handles sector-level datastore access. File recovery scans the guest file system inside the selected disk. |
Linked-clone dependency: A linked-clone descriptor can point to its source parent VMDK. Preserve the clone and referenced parent files together; the linked disk alone may not contain all blocks needed for the guest data. See Broadcom’s linked-clone descriptor example.
Before any scan:
- preserve original filenames, paths, folder relationships, timestamps where available, and every accessible related component;
- keep the source and its storage read-only;
- do not delete, consolidate, rename, edit, or mount any original component for writing;
- record which descriptor, parent, child, delta, flat, SEsparse, and split files the host still exposes;
- check whether a known-good backup is available as an alternate source, without mixing it into the original set;
- prepare a separate healthy destination for any later export.
VMDK Recovery opens files that an ESXi host exposes through SFTP. It does not parse VMFS or search deleted datastore space; VMFS Recovery handles sector-level datastore recovery when a required file is no longer exposed.
When a VMDK Snapshot Appears Corrupt: Check Available Dependencies
"Corrupt" can describe a missing component, a broken relationship, unreadable guest data, or a file that is no longer visible at the storage layer. Use observable evidence before deciding whether a bounded scan is appropriate.
Scan case: accessible, identifiable set
Evidence: Descriptor, parent, child or delta, and related extents are accessible and identifiable.
Likely indication: A plausible file-level set is available, although completeness is not proven.
Protect: Preserve the entire set together and record its layout.
Bounded scan: May fit.
Stop: The intended disk or relationships cannot be identified.
Next: Continue to the read-only workflow and validate the result.
Conditional scan: inconsistent but accessible set
Evidence: Related files are accessible, but their dependency relationship is inconsistent or uncertain.
Likely indication: Available evidence may support only a bounded virtual reconstruction attempt.
Protect: Keep every file unchanged and inventory the uncertainty.
Bounded scan: Conditional.
Stop: Selection would require invented parent, CID, descriptor, or path values.
Next: Request specialist review if the evidence cannot be classified safely.
Alternate source: known-good backup
Evidence: A known-good backup contains the required state.
Likely indication: The alternate source may be safer than an uncertain live set.
Protect: Isolate the original evidence and keep the backup separate.
Bounded scan: Usually unnecessary.
Stop: Before mixing backup files with the original set.
Next: Follow the approved backup process outside this recovery flow.
Route first: focused component assessment
Evidence: The case is specifically missing or unusable descriptor metadata, an available flat extent, identifiable SEsparse snapshot evidence, or a separate hosted split-disk layout.
Likely indication: A focused component assessment fits the corresponding guide. Broader snapshot-chain troubleshooting stays in the workflow below, including chains that contain SEsparse.
Protect: Preserve all files and their relationships.
Bounded scan: Route only for the focused case that fits its guide.
Stop: Before guessing metadata or selecting one segment in isolation.
Missing descriptor: Use Recover VMDK Without Descriptor.
Available flat extent: Use Flat VMDK Recovery.
Focused SEsparse assessment: Use SEsparse VMDK Recovery only for an identifiable snapshot component set with its required accessible parent and descriptor.
Hosted split-disk layout: Use the split VMDK assessment.
Stop and route: required file unavailable
Evidence: A required VMDK or extent is deleted, missing, or no longer exposed by the host.
Likely indication: The needed evidence is unavailable to a scan of accessible files.
Protect: Stop writes to the relevant storage and preserve what remains.
Bounded scan: No.
Stop: The ESXi host no longer exposes the required file.
Next: Use Recover a Deleted or Missing VMDK File or, when sector-level VMFS datastore recovery is required, Recover a Deleted VMDK From a VMFS Datastore.
Different outcome or unclassifiable evidence
Evidence: The required result is a restored or bootable VM, or the accessible evidence cannot be classified safely.
Likely indication: Guest-file recovery is not the requested outcome, or the case exceeds the available evidence.
Protect: Keep the source unchanged.
Bounded scan: No.
Stop: Before treating a file-recovery result as a working VM.
Next: Use Restore a VMware VM From VMDK or request recovery-specialist review.
Recover Data From VMDK Delta Files: A Safe Workflow
The workflow is limited to accessible file-level evidence. Virtual reconstruction happens inside DiskInternals Recovery Engine and uses the components that remain available. It does not rewrite the source chain or create missing sectors.
Read-Only Prerequisites Before the Scan
Related components remain together, can be connected to the intended disk, and will remain read-only.
The source may be written to, the evidence is missing or inaccessible, or a healthy separate destination is unavailable.
Return to the evidence matrix when the goal or evidence falls outside the file-level workflow.
Scan, Preview, Validate, and Export to a Separate Destination
Inventory the Available Components
Input: Every accessible descriptor, parent, child snapshot or delta, flat extent, and SEsparse snapshot redo-log file related to the intended disk. Record hosted split-disk segments separately because they belong to a different layout.
Check: Record names, locations, observed sizes, timestamps where available, and the host's file visibility.
Next: Keep the set together and compare it with the intended virtual disk.
Stop: No plausible component set remains, or identification would require assumptions.
Select the Protected Source Set
Input: The recorded, read-only component inventory.
Check: Confirm that the selection represents the intended disk and does not omit an accessible dependency. If the only usable source is an available flat extent, follow Flat VMDK Recovery instead.
Next: Add the selected local files, or connect through SFTP to files exposed by an ESXi host in a VMware vSphere environment.
Stop: The ESXi host no longer exposes a required file, or the recovery requires VMFS parsing. Use VMFS Recovery for sector-level datastore recovery.
Start the Read-Only Scan
Input: The protected set of accessible files.
Check: Confirm that the selected source is not the export destination. When dependencies are inconsistent but accessible, any reconstruction must remain virtual, bounded, and inside the application.
Next: Select the detected guest file system and an appropriate scan method when those choices are available.
Stop: The source changes, becomes inaccessible, or the software cannot identify a plausible recovery view.
Review the Scan Result
Input: The virtual recovery view produced from the available evidence.
Check: Look for the expected guest file system, folder structure, filenames, and plausible file context.
Next: Narrow the result to representative files from different folders and file types.
Stop: Results are absent, unrelated, or inconsistent with the intended virtual disk.
Preview and Validate Representative Files
Input: A representative sample of supported files.
Check: Compare expected folders, names, apparent sizes, dates where available, previewed content, and practical openability where appropriate. The free evaluation can scan the source and preview supported files.
Next: If several representative results are plausible, prepare a licensed export.
Stop: Results are incomplete, unpreviewable, unreadable, or too inconsistent to support export. Preserve the source and reassess the evidence instead of altering it.
Export Selected Files After Licensing
Input: The validated selection and a separate healthy destination.
Check: Confirm destination identity, health, free capacity, and physical separation from the affected source.
Next: Export the selected files, then open representative exported copies independently.
Stop: The destination is the source, another partition on the same affected physical disk, unhealthy, or too small.
If the required outcome is a working virtual machine rather than exported guest files, use Restore a VMware VM From VMDK. Recovering a VMDK or files from inside it does not restore the complete VM configuration or prove that the VM can boot.
Common VMDK Recovery Errors and Result Validation
A search such as "delete delta VMDK files" or "VMware VMDK corrupted after deleting snapshots" often begins after evidence has already changed. Do not try to reverse an uncertain change by making another source change. Preserve the current state, record what happened, and use the matrix to select the next safe route.
| Mistake or condition | Risk | Safe response |
|---|---|---|
| An accessible parent, child, delta, descriptor, or extent is omitted | The scan may represent the wrong point in time or an incomplete set | Stop, preserve all related files, validate the inventory, and return to the matrix |
| Related files are separated without a record of their original layout | Dependency classification becomes less reliable | Preserve the current evidence and record original and current paths where known |
| Files are renamed or moved to make the chain look consistent | Apparent relationships may no longer reflect the original evidence | Stop further changes and use the matrix or specialist review |
| Descriptor data, CID values, or other metadata is edited | Source evidence can be altered without proving that dependencies are correct | Stop, preserve what remains, and do not make another correction |
| Snapshot or delta files are deleted or consolidated | Required point-in-time data or relationships may be lost | Stop writes, inventory what remains, and use the applicable matrix route |
| A required file is inaccessible or the host no longer exposes it | File-level software cannot scan evidence it cannot read | Stop and use the deleted-container or direct-VMFS route in the matrix |
| A bounded scan produces unrelated, incomplete, unreadable, or unpreviewable results | The selected set or available evidence may not support the intended recovery | Preserve the source, validate the selection, and reassess through the matrix |
| Export is aimed at the source or an unhealthy destination | Recovered data may overwrite evidence or be placed at further risk | Stop and choose a separate healthy destination before licensed export |
Before export, confirm that:
- the selected source set matches the recorded component inventory;
- expected folders and path context appear in the recovery view;
- representative names, apparent sizes, and dates match expectations where available;
- representative supported files preview with plausible content;
- practical openability has been checked where appropriate;
- unexpected or missing results have been recorded rather than dismissed;
- the export destination is healthy, separate from the affected source, and large enough;
- the required outcome is guest-file recovery, not a bootable VM.
Preview is evidence for deciding whether to export. It does not guarantee complete recovery, file integrity, or a complete dependency chain.
VMware VMDK Recovery Software: Capabilities and Read-Only Boundaries
File-level recovery software fits only when the relevant VMDK components are accessible and the intended result is recovered guest files.
| DiskInternals Recovery Engine can | It does not |
|---|---|
| Read accessible source files without writing recovery structures back to them | Repair a VMDK, descriptor, snapshot, or delta in place |
| Open VMDK files exposed by an ESXi host through SFTP | Parse VMFS or scan deleted datastore space; VMFS Recovery handles sector-level VMFS recovery |
| Build a virtual in-app recovery view from available evidence, including a bounded dependency reconstruction attempt when the accessible set is inconsistent | Rewrite source metadata, correct descriptor or CID values manually, or reconstruct missing sectors |
| Scan a detectable guest file system and preview supported files in the free evaluation | Consolidate snapshots or restore the complete VM configuration; recovering a VMDK or its guest files does not prove that the VM can boot |
| Export selected files after licensing to a separate healthy destination | Guarantee a complete chain, complete recovery, or file integrity |
Software selection does not replace the evidence decision. Missing, deleted, split-component, VMFS-level, and complete-VM cases still require the route identified in the matrix.
Frequently Asked Questions About VMDK Snapshot Recovery
-
Snapshot-related components may be stored with the virtual disk files, but their location depends on the VMware environment and configuration. Preserve and inventory every accessible related file without moving or renaming it. If an expected file is absent or inaccessible, use the component-evidence matrix instead of assuming a universal path.
-
For guest-file recovery, preserve the accessible components and use the component-evidence matrix to confirm that a bounded scan fits the evidence. Eligible cases can then follow the read-only workflow. Deleted or inaccessible evidence, direct VMFS datastore recovery, and complete virtual-machine restoration require the separate route shown in the matrix.
-
A delta VMDK depends on an earlier disk state and may not contain all of the data needed for recovery. If its parent is missing, do not invent or edit the relationship. Preserve every accessible component and use the component-evidence matrix to decide whether the remaining evidence supports a bounded scan or needs specialist review. The software cannot reconstruct sectors that are no longer available.
-
No. DiskInternals Recovery Engine reads the accessible source files without changing them and builds a virtual recovery view inside the application. It does not rewrite descriptors or CID values, repair the source chain, or consolidate snapshots. Any recovered files must be exported to a separate healthy destination.
-
Yes, when the individual ESXi host in the VMware vSphere platform still exposes the files. VMDK Recovery reads those accessible files through SFTP. It does not parse or scan VMFS directly or undelete a VMDK component that the host no longer exposes.
-
Yes. The free evaluation can scan the accessible source and preview supported guest files. A license is required to export selected recovered files, and the export must go to a separate healthy destination.