VMware Datastore Corruption: VMFS & vSAN Recovery

VMFS and vSAN datastore issues usually surface as a VM failing to power on, a datastore showing as inaccessible or locked, or a VMDK reporting a missing or corrupted descriptor file. The underlying causes range from a failed host during a write, SAN/storage controller faults, an interrupted Storage vMotion, to a corrupted VMFS metadata journal after an unclean shutdown.

Every VMDK is actually two files: a small text descriptor file (the one referenced by the VM) and one or more large flat/extent files holding the actual disk data. It's common for the descriptor to go missing or become corrupted while the flat file — the data itself — is completely intact. Because the descriptor is a small, human-readable text file, it's tempting to hand-write a replacement. This works only if every parameter (extent size, disk geometry, adapter type) matches the original exactly; a mismatch produces a VM that boots into a corrupted filesystem rather than an error, which can be harder to diagnose after the fact.

vCenter's 'resignature' option for a datastore showing a duplicate or unresolved VMFS signature can bring a snapshot LUN back online cleanly, but it operates on the assumption that the underlying VMFS metadata is otherwise consistent. If the corruption is in the VMFS metadata itself (not just the signature), resignaturing surfaces the same errors under a new UUID rather than fixing them.

For vSAN, corruption is usually object-level rather than datastore-wide — a specific VM's objects show absent or degraded components while the rest of the cluster is healthy. Checking object health per-VM (rather than assuming a cluster-wide problem) narrows the recovery scope significantly.

If a VM won't come back after the first attempt to remount or repair the datastore, stop and image the underlying LUN or disks before trying anything else. Working from a byte-for-byte copy means every further recovery attempt — descriptor reconstruction, VMFS metadata repair, extracting files directly from the flat file — can be retried without risk to the original storage.