1. Required: root-access to an ESXi-host via ssh
2. Identify the device that corresponds to the affected datastore:
login with root account
ls -lisa | grep -v vml
In many cases you can identify the correct device by inspecting the referenced filesize – typically several hundred of GBs or several TBs.
If lots of datastores with similar size are in used – use
for a more detailed description of the available devices.
3. dd command to dump the first 1536 MB of DeviceX into a file
dd if=/dev/disks/Device:1 bs=1M count=1536 of=/tmp/Casename.1536
3a. Very often there is not enough free space available in /tmp
Workaround: dump into an archive:
dd if=/dev/disks/Device:1 bs=1M count=1536 | gzip -c > /tmp/Casename.1536.gz
3b. if that still does not work use another datastore – BUT never use the affected datastore itself!!!
dd if=/dev/disks/Device:1 bs=1M count=1536 of=/vmfs/volumes/ANOTHER-UNAFFECTED-DATASTORE/Casename.1536
4. connect to ESXiHost via WinSCP
download /tmp/Casename.1536 or /tmp/Casename.1536.gz to your admin-host and compress the file with an effective packer like 7zip or rar.
You should now have an archive that varies in size – typically range is 50 MB – 800 MB
Upload the archive to a freehostser, your webserver, or any other public location with a decent downloadrate.
(skype can be used too – but is a comparably slow option)
When upload is done – provide a downloadlink – typically this also is the perfect time for a short slype-chat
You may want to check wether the dump contains any confidential data that you are not allowed to share.
To evaluate which data is contained in a VMFS header dump download the tool strings.exe from
after download unzip strungs.exe and copy it to the same path that already has Casename.1536 open a cmd-box and execute
strings.exe Casename.1536 > Casename.1536.txt
Search through Casename.1536.txt
In most cases it takes one or two hours to get a solid overview of the prognosis and available recovery options.
There is a Knowledgebase-article that discuss the same topic – see