VMDK Recovery guide
Flat VMDK Recovery
Last updated: October 11, 2026
Flat VMDK recovery retrieves files from an available VMware -flat.vmdk data extent. Restoring a complete virtual machine is a different task.
Proceed only when the flat extent is accessible and you can keep it read-only. Results depend on the disk files that remain available and on whether the guest file system inside the virtual disk is supported. Export recovered files to a separate healthy destination.
Check the starting state first: A missing descriptor; a snapshot/delta dependency, including an SEsparse redo log; a separate hosted split-disk layout; a deleted container; VMFS-level loss; or a restore-or-boot goal requires a different recovery path. Do not guess from a filename or file size alone.
Understand VMDK Components and Storage Layers
A VMware virtual disk may include several files, but they do not all play the same role. The small VMDK descriptor stores metadata and points to one or more data extents. The larger -flat.vmdk is a data extent that contains virtual disk content. A filename, extension, or large file size helps with identification, but it does not prove that the disk set is complete or independent.
Local storage or a datastore such as VMFS holds the VMDK files and determines the available access method.
The descriptor, flat extent, and any dependencies represent the virtual disk supplied to the recovery workflow.
The file system inside the virtual disk is scanned for supported folders, files, and previews.
| Component or layer | Role in the recovery decision |
|---|---|
| VMDK descriptor | A small metadata file that identifies the 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 alone does not prove that it contains the required state. |
| Snapshot or delta component | May contain changes newer than the base extent and may require a parent-child dependency path. |
| SEsparse snapshot redo-log file | Stores the redo-log data for one snapshot in a single file and may depend on a parent disk and descriptor; it is not a numbered split extent. |
| Hosted split-disk extent | Belongs to a separate numbered-extent disk layout and may require the remaining segments. |
| Host storage, including VMFS | Stores the VMDK files and determines which product can read them. VMDK Recovery opens files exposed by ESXi but does not parse VMFS; VMFS Recovery handles sector-level datastore recovery. |
| Guest file system | Resides inside the virtual disk and is the layer scanned for supported folders, files, and previews. |
Decide Whether an Available Flat VMDK Is in Scope
Before scanning, record the visible filenames, sizes, timestamps, locations, and access method. Check component relationships and decide whether you need recovered files or a working virtual machine. These observations help classify the source; none proves that recovery will be complete.
Flat VMDK starting-state matrix
Available flat extent with no visible dependency problem
Evidence: The intended extent is accessible, the location is stable, and no unresolved dependency is visible.
Next action: Preserve the source, confirm the scan scope, and proceed with file recovery.
Stop: The file set changes, becomes inaccessible, or no longer matches the recorded state.
Flat extent without its descriptor
Evidence: The data extent remains, but the small descriptor is absent or unusable.
Next action: Keep it unchanged and follow recover VMDK without a descriptor.
Stop: Do not create or edit metadata on the source or assume that the extent is complete.
Snapshot or delta dependency
Evidence: Snapshot, delta, parent, or child files are present, or the required state is newer than the base extent.
Next action: Preserve the set and follow recover a VMDK snapshot or delta chain.
Stop: Do not assume that the base extent contains the latest state.
SEsparse snapshot evidence or hosted split-disk extents
Evidence: A SEsparse file belongs to an ESXi snapshot chain; numbered disk segments belong to a different hosted split-disk layout.
Next action: Identify the layout, keep its relationships intact, and follow the SEsparse and split VMDK guide.
Stop: Do not select one segment and assume that the other components are optional.
Deleted or missing VMDK container
Evidence: The required extent or another component is no longer available from supported host storage.
Next action: Follow recover a deleted or missing VMDK container from supported host storage.
Stop: The container needed as the source must be available before an inside-the-VMDK scan begins.
VMFS-level deletion or a restore-or-boot goal
Evidence: The datastore no longer exposes the VMDK, or the desired result is a bootable virtual machine.
Next actions: Follow recover a VMDK deleted from a VMFS datastore, or separately restore or boot a VMware virtual machine from VMDK.
Stop: VMDK Recovery opens files exposed through SFTP but does not parse VMFS or scan deleted datastore space. VMFS Recovery handles sector-level datastore recovery. Recovering a VMDK or files from inside it does not restore the complete VM configuration or prove that the VM can boot.
Confirm the available flat extent and keep the recorded source state unchanged.
Build the virtual recovery view and inspect supported files inside the application.
Check the result, then save selected copies to a separate healthy destination after licensing.
Protect the Source Before Scanning
Complete this preflight before opening the recovery workflow:
- keep the original flat extent and related files read-only;
- do not run repair attempts, rename components, consolidate snapshots, or make test changes on the source;
- record filenames, observed sizes, timestamps, source locations, and the access method;
- preserve descriptor, flat, snapshot, delta, parent, split, and SEsparse files that may belong to the disk;
- confirm authorized access to every source location you intend to use;
- prepare a separate healthy destination with enough capacity for exported files;
- use a controlled copy only when the access model and source condition make copying safe.
Stop before scanning if the source becomes inaccessible, changes during assessment, shows signs of physical instability, or reveals a dependency or storage-level problem that requires a different recovery path. Another partition on the affected physical disk is not a separate recovery destination.
Recover Files from an Available Flat VMDK
Use the following workflow only when the available flat extent matches the first case in the decision matrix. The source remains read-only, and reconstruction happens virtually inside the application. The free evaluation scans and previews supported files; licensed export saves selected files to a separate healthy destination.
VMDK Recovery opens files exposed by an ESXi host 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 when the host no longer exposes a VMDK.
Confirm the Source and Scan Scope
Compare the selected source with the preflight record: filename, location, observed size, timestamp, and access method. Confirm that the scan target is the protected source, not the export destination, and that the source remains accessible and unchanged.
These checks support identification; they do not prove that the disk set is complete. Stop and return to the decision matrix if you find an unresolved dependency, a deleted container, a VMFS-level need, or a restore-or-boot goal.
How to Recover VMDK from Flat File
- Keep the available flat extent and related files read-only.
- Add the available VMDK set as the source in VMDK Recovery.
- Select the recovery depth supported by the guest file system and appropriate to the loss.
- Run the scan and review the virtual recovery view inside the application.
- Preview representative supported files and confirm their folder context.
- After licensing, export only the files you need to a separate healthy destination.
Stop check: If source details or dependencies no longer match the first case in the decision matrix, stop rather than changing the source or forcing the scan to continue.
Create a Read-Only Recovery View and Preview Files
The scan uses readable structures and data to build a recovery view inside the application. It does not rewrite the flat extent. Browse reconstructed folders and compare filenames, folder paths, file sizes, and representative previews with the result you expected.
Preview is an assessment tool. Not every file type is previewable, and a successful preview does not prove that every missing file was found or that every export will succeed.
Stop check: If expected files are absent, folder context is inconsistent, or preview is unsupported or incomplete, reassess the selected source and scope instead of modifying the original VMDK.
Verify and Export Files to a Separate Healthy Destination
Before export, check representative filenames, folder paths, file sizes, previews, and expected file context. After licensing, export selected files to a separate healthy destination with enough capacity.
Confirm that the exported copies exist at the destination and can be opened independently. Export does not repair the source or prove that every missing file, dependency, or sector was recovered.
Stop check: Stop and reassess if verification fails, the result is incomplete, or the destination is unhealthy.
Understand Virtual Reconstruction and Product Boundaries
Virtual reconstruction is a read-only recovery view inside the application. It is not source repair. This workflow does not rewrite the flat extent, recreate missing sectors, 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.
Repair VMDK Flat File Without Rewriting It
The phrase repair VMDK flat file means recovering usable files through a virtual view while leaving the source unchanged. The result is a verified copy at another destination, not a modified flat extent.
Repair Corrupt Flat VMDK Files by Reconstructing a Recovery View
If you need to repair corrupt flat VMDK files, first determine whether the available extent is readable and still in scope. Readable structures may support a browsable recovery view, but the process cannot recreate missing sectors or guarantee a complete dependency chain.
For the product, free-evaluation, and pricing path, see DiskInternals VMDK Recovery. It uses the DiskInternals Recovery Engine for the read-only file-recovery workflow described here.
Common Errors and Stop Conditions
Review the decision matrix again whenever the source evidence no longer matches its first case.
| Observable problem | Safe action | Stop condition |
|---|---|---|
| A descriptor, snapshot, split segment, or unrelated file was selected instead of the intended flat extent. | Compare the selection with the preflight inventory and identify the intended data extent. | Stop if the data extent cannot be identified without guessing. |
| A missing dependency or inaccessible file is being treated as ordinary flat-file corruption. | Reassess component relationships and choose the matching recovery path in the matrix. | Stop if a required component is missing or the host no longer exposes it. |
| The source is changing, disconnecting, slowing sharply, or reporting new read errors. | Preserve the current evidence and reassess the source condition. | Stop all software scanning when continued reads may worsen the source. |
| The scan target or scope does not match the preflight record. | Recheck source versus destination and select only the recorded flat extent. | Stop if the selected target is not the recorded flat extent. |
| An empty, incomplete, or unsupported preview is being treated as proof that the source can be fixed in place. | Check folder context, expected files, file type support, and the starting-state classification. | Stop and reassess; do not modify the source or assume that another scan will repair it. |
| Export points to the source, an unhealthy disk, or a destination without enough capacity. | Select a separate healthy destination and confirm available space. | Stop before export if the destination can overwrite source evidence or cannot hold the copies. |
| SFTP file access is being used for direct VMFS recovery, host undelete, or a complete-VM goal. | Use the matching VMFS recovery or VM restoration option in the decision matrix. | Stop when the required file is not exposed or the goal is not file recovery. |
If you arrived here by searching how to fix flat VMDK or flat VMDK repair, use the observable source state—not the word “corrupt”—to choose the next action. Repeated scanning and source changes are not substitutes for the correct recovery path.
Flat VMDK Recovery FAQ
-
No. The recovery view exists inside the application. The workflow does not write reconstructed structures back to the original flat extent.
-
No. VMDK Recovery opens files exposed by an ESXi host through SFTP, but it does not parse VMFS or scan deleted datastore space. VMFS Recovery handles sector-level recovery from VMFS when a VMDK is no longer exposed by the host.
-
It means the result needs reassessment. Check the source selection, guest file system, folder context, preview support, and decision-matrix state. Do not treat a missing preview as proof that the source can be repaired in place.
-
Export them to a separate healthy destination with enough capacity. Do not use the source or another partition on the same affected physical disk.
-
Stop the scan and preserve the evidence you still have. Review the decision matrix and reassess the source condition, access method, and recovery path before continuing.
-
Yes. The free evaluation can scan the accessible source and preview supported guest files. A license is required to export selected recovered files to a separate healthy destination.