VMware Snapshot Manager Shows Corrupted Snapshot – Fix

Quick answer: Run vmkfstools -x repair -v 10 /vmfs/volumes/datastore/vmname/vmname.vmdk on the base disk and each snapshot delta VMDK.

Why This Happens

You're in the vSphere Snapshot Manager and see a snapshot listed as Corrupted. It might show a red X, or the consolidation button stays greyed out. The VM still runs, but you can't delete or consolidate that snapshot.

What's actually happening here is the snapshot's metadata file — a CTK (Change Tracking) file — has a checksum mismatch with the actual data blocks on disk. This usually happens after an unclean shutdown of the ESXi host, a storage motion that gets interrupted, or a backup tool that didn't release the snapshot properly. VMware's vSphere UI sees the mismatch and marks the snapshot as corrupted to prevent you from accidentally breaking the VM's disk chain.

The reason the snapshot won't delete is that the UI checks the CTK file integrity first, and if it's bad, it refuses to touch the snapshot chain at all. It's a safety feature, but it's annoying when you just want to clean up.

Fix Steps

Check if the VM is powered on. You'll need to power it off for the repair to work. If it's a critical production VM, schedule a brief downtime. In my experience, trying to repair while the VM is running almost always fails with a locked-file error.
SSH into the ESXi host that has the VM's datastore mounted. Use an SSH client like PuTTY or OpenSSH. Credentials are usually root and your host password.
Locate the VM's directory. Run this command to find the datastore path:
```
cd /vmfs/volumes/datastore/vmname/
```
Replace datastore with your datastore name and vmname with the VM folder name.
List all VMDK files in the directory. You'll see the base disk (like vmname.vmdk) and snapshot deltas (like vmname-000001.vmdk). Run:
```
ls -la *.vmdk
```
Repair each VMDK starting from the base disk. The command format is:
```
vmkfstools -x repair -v 10 vmname.vmdk
```
The -v 10 flag gives verbose output so you can see what it's fixing. Do this for the base VMDK first, then each snapshot delta in order (000001, 000002, etc.).
Verify the snapshot is no longer corrupted. In the vSphere Client, right-click the VM > Snapshots > Manage Snapshots. The corrupted status should be gone. If it still shows, try consolidating: right-click the VM > Snapshots > Consolidate.

Alternative Fixes If the Main One Fails

If vmkfstools -x repair doesn't clear the corrupted status, you have two options:

Delete the snapshot manually via SSH. This is riskier but works when the repair doesn't. First, find the base disk's descriptor file with cat vmname.vmdk and note the parent disk chain. Then delete the snapshot delta VMDK files (the -00000x.vmdk ones) directly with rm, then edit the base descriptor file to remove references to the deleted child disks. This is advanced — if you mess up the chain, the VM becomes unbootable. Only do this if you have a backup.
Restore from a known-good backup. If the snapshot chain is truly broken beyond repair, restore the VM from your backup. Yes, it's painful, but it's safer than risking data corruption from manual chain editing.

Prevention Tip

Don't let snapshots sit for more than 72 hours. The longer a snapshot chain grows, the more likely the CTK metadata gets out of sync — especially if you do storage vMotion with snapshots present. I've seen this happen most often when people leave snapshots for weeks because they think it's a backup. It's not. Consolidate snapshots within 24-48 hours after creation. Set a calendar reminder if you have to.

Note: If you see a corrupted snapshot after a backup tool like Veeam or NetBackup runs, that tool's snapshot release mechanism failed. Contact their support — it's usually a bug in the backup software, not VMware.