VMDK Recovery guide
Recover VMDK Without Descriptor
Last updated: October 11, 2026
A missing or unusable VMDK descriptor does not necessarily mean that the guest files are gone. The descriptor is a small metadata file; the virtual disk data normally resides in one or more extents.
If an accessible extent or related disk component remains, DiskInternals VMDK Recovery can attempt a read-only scan and build a virtual recovery view inside the application. The goal is to find, preview, and export guest files, not to edit the source, rebuild VMware metadata by hand, or make a virtual machine bootable.
Start with the evidence: Inventory the descriptor, data extents, snapshot or delta files including SEsparse redo logs, separate hosted split-disk extents, storage location, and access method. A filename or file size alone does not prove that a disk set is complete.
Restore VMDK Descriptor File: Choose the Safe Recovery Goal
Searches for how to restore VMDK descriptor file often lead to instructions for creating metadata manually. DiskInternals VMDK Recovery uses a different method: it keeps the source unchanged and attempts to recover guest files through a virtual view inside the application.
Scan the accessible components read-only, preview supported files, and export selected copies separately.
Stop. The product does not rewrite the descriptor or repair the VMDK container in place.
Use the VMware VM restoration path. Available VM configuration files can be recovered as files, but file recovery does not restore the complete VM configuration or prove that the VM can boot.
VMDK Header File Corrupt: Protect the Remaining Components
The wording “VMDK header file corrupt” can refer to missing or unusable descriptor metadata, but it does not identify the condition of the data extent or guest file system. Preserve every available component and use observable evidence to choose the recovery path. Do not replace or edit source metadata as a diagnostic test.
Fix VMDK Header: What Recovery Can and Cannot Do
For “fix VMDK header” searches, the safe distinction is between recovering files and modifying the virtual disk. DiskInternals VMDK Recovery can attempt read-only reconstruction of a browsable result inside the application. It does not rewrite the descriptor, recreate missing sectors, consolidate snapshots, or restore the complete VM configuration. Available VM configuration files can be recovered as files, but file recovery does not prove that the VM can boot.
Corrupt VMDK Descriptor File: Assess the Remaining Disk Set
A corrupt VMDK descriptor file may leave the data extent untouched, but that cannot be assumed from the descriptor error alone. Compare all accessible files with the intended disk context. Unknown dependencies, missing components, or an unavailable extent are reasons to stop and return to the decision matrix.
Invalid VMDK Image Descriptor: Choose the Next Recovery Path
An invalid VMDK image descriptor message identifies a metadata or access problem, not a guaranteed recovery outcome. If the remaining disk set is plausible and accessible, continue with the read-only workflow. If the extent is missing, the host no longer exposes the file, or the goal is VM restoration, use the matching route in the matrix.
Understand the Descriptor, Data Extent, and Guest Files
A VMware virtual disk can be represented by several related files. They have different jobs and should not be treated as interchangeable.
Local storage or a VMware datastore holds the available VMDK files.
Descriptor metadata, data extents, and dependent components describe the supplied virtual disk.
The file system inside the virtual disk is scanned through a virtual recovery view.
| Component or layer | What it means for recovery |
|---|---|
| VMDK descriptor | A small metadata file that describes the virtual disk layout and points to its extent or extents. It is not the guest data itself. |
-flat.vmdk data extent | Contains virtual disk data. Its name or size does not prove that every required dependency is present. |
| Snapshot or delta component | May contain changes newer than the base extent and may require a valid parent-child chain. |
| SEsparse snapshot redo-log file | On ESXi, the snapshot redo-log data is stored in a single -sesparse.vmdk file; a descriptor may be a separate companion and the snapshot may depend on a parent disk. It is not a numbered split extent. |
| Hosted split-disk extent | One numbered part of a separate hosted split-disk layout; the other segments may be required. |
| Host storage | VMDK Recovery opens files exposed by an ESXi host through SFTP but does not parse VMFS; VMFS Recovery handles sector-level datastore recovery. |
| Guest file system | The layer inside the virtual disk that is scanned for recoverable folders, files, and supported previews. |
The missing descriptor is only one part of the path. Recovery still depends on surviving data, component relationships, guest file-system condition, and source access.
Protect the Source and Confirm the Recovery Prerequisites
Complete these checks before scanning:
- keep the original VMDK files and their storage read-only;
- preserve every accessible descriptor, flat extent, snapshot, delta, parent, split, and SEsparse component;
- do not rename components, consolidate snapshots, recreate metadata, or test changes on the source;
- record filenames, observed sizes, timestamps, locations, and access methods;
- confirm that at least one plausible data extent or related component remains accessible;
- confirm authorized local access or access to exposed files on an ESXi host in a VMware vSphere environment;
- prepare a separate healthy destination with enough space for exported files.
Stop before scanning if the source changes, becomes inaccessible, shows signs of physical instability, or cannot remain protected from writes. Also stop when no accessible data extent remains or when the intended disk set cannot be identified without guessing.
VMDK Recovery opens files exposed by an ESXi host in a VMware vSphere environment through SFTP but does not parse VMFS or search deleted datastore space. VMFS Recovery handles sector-level datastore recovery when a required file is no longer exposed.
Choose a Safe Recovery Path From the Remaining VMDK Evidence
Classify the starting state before selecting a source. Each case has a different stop condition and next action.
Missing descriptor with an accessible extent
Evidence: The descriptor is absent or unusable, while a plausible data extent or related component remains accessible.
Next action: Preserve the full set and continue with the read-only workflow below.
Stop: The files cannot be connected to the intended disk without assumptions.
Available -flat.vmdk extent
Evidence: A flat extent is accessible and the goal is guest-file recovery rather than descriptor assessment.
Next action: Use Flat VMDK Recovery.
Stop: Dependent components may contain the required state.
Snapshot or delta-chain evidence
Evidence: Snapshot, delta, parent, or child components are present, or the required state may be newer than the base extent.
Next action: Use VMDK Snapshot Recovery.
Stop: The parent-child relationship or required point in time is unknown.
SEsparse snapshot evidence or hosted split-disk extents
Evidence: On ESXi, an SEsparse snapshot redo log is stored in a single -sesparse.vmdk data file; numbered segments belong to a separate hosted split-disk layout.
Next action: Identify the layout, preserve its components, and use SEsparse and Split VMDK Recovery.
Stop: A required component is unavailable or the relationship is uncertain.
Deleted or missing VMDK container
Evidence: The required VMDK or data extent is no longer exposed by the ESXi host or available from supported host storage.
Next action: Use Recover a Deleted or Missing VMDK File. For VMFS-level deletion, use Recover a Deleted VMDK From a VMFS Datastore; VMFS Recovery handles sector-level datastore recovery.
Stop: SFTP is the only access method and the host no longer exposes the required file.
Restore or boot a complete virtual machine
Evidence: The required result is a working VMware virtual machine rather than exported guest files.
Next action: Use Restore a VMware VM From VMDK.
Stop: Do not treat a file-recovery result as proof that the VM can boot.
Use the Read-Only Missing-Descriptor Recovery Workflow
The workflow uses DiskInternals Recovery Engine to build a virtual recovery result without writing reconstructed structures back to the VMDK.
Inventory the Available Disk Set
Record all accessible VMDK components, locations, observed sizes, timestamps, and the intended virtual disk. Keep the files unchanged.
Check: At least one plausible data extent or related component remains accessible.
Stop: No accessible extent remains, or the files cannot be connected to the intended disk without guessing.
Confirm the Selected Disk Set Before Scanning
Compare filenames, locations, apparent relationships, component types, and the intended disk context. Matching names or folders do not prove a complete dependency set.
Check: The selection matches the missing-descriptor case in the decision matrix.
Stop: A snapshot, split, SEsparse, deleted-container, direct-VMFS, or VM-restoration path is more appropriate.
Add the Accessible Source
Open the available local disk files, or use VMDK Recovery to connect through SFTP to files exposed by an ESXi host in a VMware vSphere environment. Open the selected VMDK as a disk in the program before scanning its guest file system.
Check: The selected source is the protected VMDK set, not the export destination.
Stop: The host does not expose the required file, source access changes, or VMFS-level recovery is required; use VMFS Recovery for sector-level datastore recovery.
Scan the Guest File System
Choose the recovery depth supported by the guest file system and appropriate to the loss, then run the scan. Reconstruction remains virtual and inside the application.
Check: The result contains a plausible folder and file context for the intended virtual disk.
Stop: Results are absent, unrelated, or inconsistent with the expected guest file system.
Preview Representative Files
Use the free evaluation to inspect supported files. Compare expected folders, filenames, apparent file sizes, and representative previews.
Check: Several representative results match the expected content and context.
Stop: Results are implausible or do not support export. Preview helps assess results; it does not prove completeness.
Export Selected Files After Licensing
Confirm destination capacity, then export only the files you need to a separate healthy destination. Never export to the original source or another partition on the same affected physical disk.
Check: Exported files exist at the destination and can be verified independently.
Stop: The destination is unhealthy, lacks capacity, or can overwrite source evidence.
For the free evaluation and pricing path, see DiskInternals VMDK Recovery.
Inspect, Preview, and Export to a Separate Destination
The free evaluation of VMDK Recovery lets you select a source, scan it, review the files and folders found, and preview supported file types. Use several representative files to judge whether the result matches the expected guest data.
Build a virtual recovery view without rewriting the original VMDK.
Check folders, names, apparent file sizes, and representative supported files.
Save selected recovered files to a separate healthy destination.
Preview is not a guarantee that every missing file was found or that a recovered virtual disk can boot. A license enables export of selected recovered files; it does not repair the VMDK source.
Export boundary: Save recovered files only to a separate healthy destination. Another partition on the same affected physical disk is not a separate recovery destination.
Verify Exported Files and Resolve the Next Action
Keep the original source unchanged until the exported data has been checked.
Post-Export Verification Checklist
- compare the exported folder tree with the recovery view;
- open representative files from the destination;
- compare expected and apparent file sizes;
- check files in the appropriate application when one is available;
- confirm that the destination contains the required copies before changing any source or storage workflow;
- record missing, unreadable, unrelated, or implausible results.
Recovery limits: Available VM configuration files can be recovered as files, but this workflow does not recreate missing sectors, guarantee a complete dependency chain, consolidate snapshots, repair descriptor metadata in place, restore the complete VM configuration, or prove that the VM can boot. VMDK Recovery opens files exposed by an ESXi host through SFTP but does not parse VMFS or search deleted datastore space. VMFS Recovery handles sector-level datastore recovery when a required file is no longer exposed.
Representative files are plausible and open correctly. Continue checking the exported data.
Results are absent, unrelated, unreadable, or implausible. Keep the source unchanged.
The available components or desired result belong to another recovery path.
Recover VMDK Without Descriptor FAQ
-
Possibly. A missing descriptor does not necessarily remove the virtual disk data. Recovery depends on whether an appropriate data extent or related component remains accessible, whether the disk set can be identified, and what data is still readable.
-
No. The recovery workflow reads the available source and builds a virtual view inside the application. It does not rewrite descriptor metadata on the source.
-
Yes. VMDK Recovery opens accessible files exposed by an ESXi host through SFTP but does not parse VMFS or search deleted datastore space. VMFS Recovery handles sector-level datastore recovery when a required VMDK file is no longer exposed.
-
Yes. The free evaluation scans the source, shows the files and folders found, and previews supported file types. A license is required to export selected recovered files.
-
No. Preview helps assess representative files. It does not prove that every dependency is present, every missing file was found, or that the VM can boot.
-
Save them to a separate healthy destination with enough capacity. Do not export to the source or another partition on the same affected physical disk.