VMware snapshot-chain recovery

A corrupt VMware redo log can hide the newest guest writes even while the base VMDK remains readable.

VMware snapshots store changed blocks in child VMDKs rather than copying the full virtual disk. If a descriptor, CID relationship, sparse extent, or metadata table is damaged, the VM may fail to start or consolidation may stop.

Start a recovery case Call 682-325-7712

Understand the symptom

The visible guest disk is a layered result assembled from base and child extents.

WHY

What is happening

Each child points to a parent and contributes newer blocks. Descriptor CIDs help validate lineage, while sparse extent metadata maps allocated grains. A broken link or corrupt redo log can make the entire virtual disk appear unavailable even though many layers remain individually readable.

What you may see

Symptoms that change the recovery path.

Cannot open the disk

ESXi or Workstation reports a parent, CID, descriptor, or redo-log error.

Snapshot consolidation fails

A child extent cannot be read, locked, or matched safely to its parent.

VM boots to an older state

The base disk opened without one or more valid child layers.

Delta files are unexpectedly large

Long-lived snapshots or failed consolidation may contain substantial unique data.

Protect the source

Actions that can make the situation worse.

Snapshot deletion commits writes

Consolidation changes the disk chain and can propagate corruption into the base.

CID edits can force a false lineage

Making descriptors agree does not prove the blocks belong to the same history.

Datastore cleanup removes children

Small descriptors and large delta extents are both required.

Do this now

Safe steps before evaluation.

Power off the VM

Stop backup, replication, snapshot, storage-vMotion, and consolidation tasks.

Preserve the complete folder

Copy all VMDKs, VMX, VMSD, NVRAM, logs, lock context, and related snapshots.

Record datastore errors

Save vmware.log, host events, chain errors, file listings, timestamps, and storage health.

Protect unstable backing storage

Image or snapshot the datastore at the storage layer before additional reads when media is failing.

NEPFOSYS process

How a data-first evaluation proceeds.

Chain and extent inventory

NEPFOSYS maps descriptors, CIDs, parents, sparse extents, and snapshot chronology.

Layer reconstruction

Readable blocks are assembled in the correct order on protected working copies.

Guest verification

Filesystems, databases, and selected guest data are validated from the reconstructed view.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

Can I edit the parentCID to make the VM start?

A matching text value does not prove block lineage. Preserve the chain and validate the actual extents first.

Does deleting a snapshot remove only temporary data?

No. A delta can contain the newest and only copy of changed guest blocks.

Why save vmware.log?

It can record disk opens, paths, parent relationships, snapshot operations, and the first failing extent.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case