SEsparse VMDK Recovery

Inventory the Available Evidence Before Opening It

Treat the inventory as an evidence log, not as a list of files you expect to be related. Record what is actually visible before opening any component in recovery software.

1. Define the objective. Record the guest-file recovery goal and identify the intended virtual disk or virtual machine by a name meaningful in the current environment.
2. Record visible files. Copy the exact name, extension, original directory, observed size, and timestamp of every accessible related file. Preserve capitalization and numbering exactly.
3. Record access. Note whether the source is local or exposed by an ESXi host over SFTP. For remote access, record the host and source directory.
4. List dependencies. Note each descriptor, parent, extent, snapshot, delta, or other dependency indicated by the available evidence, including anything expected but unavailable.
5. Classify the source. Use observable evidence to identify an accessible SEsparse set, a complete available split set, or an out-of-scope state from the matrix.
6. Prepare the destination. Record the physical destination, free space, and folder that will receive licensed exports.

Swipe or scroll horizontally to read the diagram. Use arrow keys when focused.

Observable check: The intended source set can be identified from available evidence without relying on an extension alone or guessing a missing relationship.

Next: Record go only when the evidence fits one of the first two matrix cases. Otherwise record no-go and use the matching route there.

Start a Read-Only Virtual Reconstruction

Install and run DiskInternals Recovery Engine from the healthy Windows recovery environment, never from the affected storage. Work with the protected local evidence or connect only to files that an ESXi host still exposes over SFTP.

Select the intended source through the normal VMDK-opening flow and compare it with the inventory before scanning. Confirm the path, visible filenames, observed sizes, and access method. When several virtual disks or similarly named directories exist, stop and resolve identity from environment records instead of choosing by filename alone.

DiskInternals Recovery Engine uses available evidence to form a virtual recovery view inside the application. This is not an in-place repair and does not modify the original files.

Swipe or scroll horizontally to read the diagram. Use arrow keys when focused.

For remote source files, VMDK Recovery opens files exposed by the ESXi host through SFTP, but it does not parse VMFS or search deleted datastore space. If a required component is no longer exposed, use VMFS Recovery for sector-level datastore recovery.

• the selected input matches the source set recorded in the inventory;
• the application is not pointed at the destination or an unrelated VMDK;
• every accessible related component remains in its preserved location;
• the source remains stable and unchanged during access;
• the application presents a plausible virtual disk or guest file-system view rather than only an isolated unclassified file.

Observable check: The application identifies a plausible virtual disk or guest file-system view that corresponds to the intended source.

Next: Continue only while the source remains unchanged and the in-app view remains consistent with the inventory.

Scan for the Guest Files You Need

Define a small representative target set before scanning. Include important files from different folders and types whose expected content or approximate size is already known. This gives the scan a practical success criterion other than a large result count.

Start a scan only from the usable virtual view. The free evaluation can scan supported guest files, but discovery in a result list does not prove that a file is intact or exportable.

• keep the source set and remote access path unchanged;
• do not move, rename, replace, or add components to alter the result;
• do not start a second competing scan against the same evidence;
• record disconnects, read errors, path changes, or a changing result context;
• compare emerging folders and files with the representative targets instead of judging only by item count.

Observable check: Record whether representative needed folders and files appear with plausible names, locations, apparent sizes, and dates where available.

Next: Select a representative sample across different folders and file types for preview. Favor files whose expected content is already known.