As you probably already know none of the VMFS-versions so far has an “Undelete” function.
So there is no way to restore a virtual disk if it was deleted manually by accident in a reliable way.
In the past few years I learned some procedures to work around this VMFS-limitation.
But to tell you the bad news first – none of this procedures is 100% reliable.
So if you ask me : “Can you recover a vmdk that I deleted accidentaly ?” the answer will always be: “it depends …”
The most critical aspects are:
|activity on the VMFS-datastore after the VMDK
creation of new
vmdks or snapshots
|attempts to recreate files using dummy disks
a la VMware Knowledgebase
|Size of the VMDK||large||small|
|ESXi Version||6.0 and later||3.5 – 5.*|
|free space on the datastore at the time the VMDK was created||no free space
or almost full
|lots of free space|
To estimate the chances for a recovery it is required to understand that there are 2 possible cases:
Case 1: the location of the VMDK inside the VMFS-volume is still referenced in the VMFS-Metadata.
Case 2: the location of the VMDK inside the VMFS-volume has to be guessed
ESXi 3.5 upto 5.* usually simply dereferenced the name of the VMDK without cleaning the Inode and the mapping details.
The Linux-tool vmfs-fuse very often still displayed the VMDK as if it had never been deleted.
This behaviour seems to have changed with ESXi 6. With the new version the “delete file” process now does a cleaner job.
Unfortunately vmfs-fuse no longer works with VMFS 6
Let me give you a quick overview of the procedure that I use nowadays:
1. user deletes a VMDK
2. as soon as this gets noticed the following steps will improve the chances for a successful recovery:
– do not create new VMs on the datastore
– do not create new snapshots on the datastore
– if possible power off all VMs that use thin-provisioned VMDKs
– collect information about the lost VMDK such as size, filesystem, provisioning type, guestOS
3. create a dump of the first 1.5 Gb of the VMFS-volume
4. contact me
5. the dump of the VMFS-header-files can then be used to find out if an attempt to recover the deleted VMDK makes sense or not.
I need about an hour to analyse the dump and once I got the results we can discuss what to do next.