Recovery methodsTechnical

Virtual Disk Snapshot and Differencing-Chain Recovery

A virtual machine snapshot is not a copy of the whole disk — it is a layer that inherits everything it did not change from its parent, so recovery has to reconstruct which block comes from which generation before the guest disk can be trusted at all.

A snapshot chain is a layered block-address map

A sparse or differencing virtual disk is not simply a large flat file: it maps a guest logical block address through the current image's own allocation metadata, and when that block is not present in the current image, the lookup falls through to the parent image, then to that parent's own parent, and so on back to the base disk. Reading one guest sector can therefore mean walking several files in sequence before the actual bytes are found — a VM snapshot chain is fundamentally a layered block-address map, not a set of independent full copies.

VMDK identifies generations with CID and parentCID

VMware's descriptor metadata for a VMDK includes a CID for the current disk state, a parentCID identifying which parent generation the child expects, and a parentFileNameHint pointing at that parent file. Broadcom's own documentation is explicit that a healthy chain requires the child's parentCID to match the parent's actual CID. VMDK snapshot recovery is fundamentally a parent-child generation matching problem, not a filename-sorting exercise — the descriptor's CID relationship is the authoritative link, not the numbering in the filenames.

Filenames suggest chronology, but are not proof of it

Names like vm.vmdk, vm-000001.vmdk and vm-000002.vmdk usually do reflect the order snapshots were taken in, but chain reconstruction should rely on the descriptor's CID, parentCID and parentFileNameHint, the VM's own configuration and snapshot metadata, file timestamps and logs, and actual data consistency — not simply on assuming the numerically highest snapshot is the correct active top. Configuration changes or a prior consolidation can leave naming that no longer reflects the real chain structure.

A CID mismatch is a warning, not a cosmetic error

Broadcom documents CID-mismatch errors as arising from incomplete snapshot operations, manual descriptor editing, parent-disk modification, a broken or missing link in the snapshot chain, or copying an inconsistent set of VM files. The mismatch check exists specifically to prevent silently combining incompatible generations. Editing the ID to make the error go away does not fix anything real — it can produce a disk that is logically inconsistent while no longer reporting the problem.

A missing intermediate snapshot can permanently remove unique blocks

In a chain running base → 000001 → 000002 → 000003, if 000002 goes missing, any blocks that were changed only in 000002 can be absent from the base, from 000001, and from 000003 if 000003 never happened to rewrite those same blocks again. A later snapshot does not necessarily contain all the data implied by its missing parent — snapshots are deltas describing changes, not cumulative independent copies of everything before them.

Consolidation is destructive to historical layering

VMware documents snapshot consolidation as merging delta changes into parent or base files, which is an entirely normal operational action. For recovery, though, consolidation reads source extents, rewrites parent and base blocks, changes the historical chain structure, and can create new problems if it fails partway through. The only evidence copy of a broken chain should never be consolidated merely to see whether the VM starts — preserve first, experiment on a copy.

A descriptor without its extent is not a usable disk

A VMDK can be split between a small descriptor file and a large extent file — disk.vmdk plus disk-flat.vmdk, a snapshot descriptor plus its -delta.vmdk, or seSparse variants of the same idea. Losing the descriptor does not automatically mean the large extent payload is lost, since the descriptor can sometimes be reconstructed from what the extent itself and the VM configuration imply. The reverse is not true: having a descriptor without the extent it references is not a usable virtual disk, whatever the descriptor itself still says.

Reconstruct the chain virtually, not destructively

The safer approach mirrors RAID reconstruction: build a read-only, virtual model of the preserved base and snapshot files, expose the resulting guest disk through that model, and only then hand it to guest filesystem recovery — rather than editing original descriptors, consolidating, booting the VM directly, or writing back through the guest. See Storage Metadata Generations and Consistency for the same underlying principle applied to RAID and array metadata.

Practical rule

Preserve the entire VM directory — base disk, every snapshot file, configuration and snapshot metadata — before assuming which file is the correct active top of the chain.