Recover Deleted VMDK from Datastore Today
In this article, you will find out:
- The most widespread reasons for VMDK deletion.
- 4 important questions for the recovery process.
- How to recover deleted VMDK files from datastore.
- VMFS Recovery™ requirements.
Are you ready to cope with deleted VMDK? Let's read!
Why were my VMDK files deleted?
Like any other kind of file, VMDK files can be accidentally or intentionally deleted.
VMDK files can be removed during the migration from one ESX space to another, due to damage to one or several storage disks. Of course, there are many other, less common reasons that lead to VMDK deletion, but in any case, you can recover deleted VMDK files from a datastore or at least try to do it.
An interesting case of VMDK deletion happens with adding one disk to a VM. Immediately, two files are created simultaneously: .vmdk files and -flat.vmdk files. Therefore, these two files, or one of them, can be deleted. If you remove or lose for any reason the .vmdk file, it can be recovered by adding one disk to the VM and select “use saved VMDK”.
But if you have deleted the -flat.vmdk file, there is no chance you can recover it by yourself. You need a reliable software: VMFS Recovery™.
1. What is the version of ESX/ESXi on the server?
This issue is fundamentally important, since some of the older versions of ESXi have file size restrictions. In addition, new versions of ESXi have a number of functions that are simply not available in older versions. The difference is also present between VMFS versions 5 and 6: they are very actual right now, but totally different.
VMFS Recovery™ in turn, works with VMFS partitions created in VMware vSphere 3.5-6.5 and ESX/ESXi VMware® ESX Server™.
2. VM provision: thick or thin?
The ability to recover deleted VMDK from a datastore depends on how the file’s is provisioned: “thin” or “thick”.
A “thick” provision of a VMDK file is easier to restore than a “thin” one. It is a consequence of the fact that the data of “thin” and “thick” provisions are located differently. “Thin” provisioned files has a more complex organization, as the space assignment is distributed as needed. The complex organization is the reason why recovering deleted VMDK files from a datastore with “thin” provision is a more difficult process.
3. What was the guest OS hosting?
This is very important, since the scan can only be configured for a specific OS.
VMFS Recovery™ will recover deleted VMDK files, but for searching for particular VMDK files, what really matters is what operating system this VMDK file is on, because it does matter what file system it has.
VMFS Recovery™ works with the following file systems: RAIDZ, ZFS, FAT32, EXT4, NTFS 5, EFS, ReiserFS, disk spaces, XFS, Hikvision, HFS, HFS+, and ReFS.
4. Was a RAID server a VMDK datastore?
The RAID server does not directly affect the deleted VM, but problems with VMFS disks may be associated with it.
It is possible that RAID will bring the outdated disk back online, and this will corrupt the file system. From the side, it seems that the VMDK files have been deleted or a virus attack has occurred.
Another situation may be a disk or RAID controller “dies” and you need to rebuild RAID and read VMFS. VMFS Recovery™ works with VMFS disks stored on all types of RAIDs, including RAID JBOD, 0, 1, 1E, 0 + 1, 1 + 0, RAID 4, RAID 5, 50, 5EE, 5R, RAID 6, and 60.
The most important tip to recover deleted VMDK
Do not recreate the VM!
This can lead to a rewrite of the original data and will inevitably delete the main and auxiliary files. And recovery of the deleted VM from the datastore will be much harder and less likely to be successful.
Technicians usually know this well and try to avoid rewriting. But still, it is good to offer a reminder!
Guide: recover deleted VMDK files from a datastore
You can study this in detail and then use the instructions to recover deleted VMs from a datastore using the reliable and professional VMFS Recovery™ software tool from DiskInternals.
Step 1. In order to restore deleted VMDK files from a datastore, you need to run the downloaded executable file.
Step 1.1 There are many ways to access the VMFS disk:
- Direct connection of the VMFS disk to another computer with Windows and launch VMFS Recovery™
- SSH connection
- Access to the datastore from VM with Windows and launch VMFS Recovery™ inside of the same ESX/ESXi
- Boot Windows in ESX/ESXi from external storage (USB flash drive, HDD, SSD) and than start VMFS Recovery™
- Network connection using the iSCSI interface or Fibre Channel
Step 2. Scan the VMFS disk. This process may take some time, so wait.
Step 3. A new window with search results will appear on the screen. Locate the correct VMDK file. Now mount this file with the .vmdk extension as a disk.
Step 4. Open the disk and click the Scan button. This is necessary in order to check whether the files can be recovered.
Step 5. Preview. Right-click on the file and select “Preview in a new window”. After completing this action, you will confirm the integrity of your data.
Step 6. To save found data, you will need to purchase a license for VMFS Recovery™. After you enter a license key, you need to start the save wizard to recover VMDK files from a datastore and save it on Windows. When you have your VMDK files on Windows, you can bring them back on ESX. If the VMDK was damaged, you will need to recreate a new VM and upload the recovered data into this new VM.
Requirements for VMFS Recovery™
In order to use VMFS Recovery™ and seamlessly recover deleted VMDK from a datastore, you should keep the following in mind:
- The computer should work under the Windows operating system, and it should not be older versions, but at least 7. Ideally, it is best to use Windows 10. This is important, because before starting to recover deleted VMDK files, it creates the entire VMFS structure in RAM (at least 6 GB in size, 16+ is perfect!).
- There should be enough disk space. The software itself is about 65 MB. But a lot of free space is needed for the recovered files. Therefore, consider the size of the virtual machine data you are restoring and calculate the approximate space.