File systems peculiarities
Issues that are normally fixed at this point are formatted partitions, deleted files, or access to the data that is stored on a file system that is not supported by Windows.
Please note: before recovering file system data, you need to make sure that the disk is ok. If you suspect there is some problem with a disk(such as bad blocks, damaged or corrupt RAID configuration) you need to solve the disk problem first before continuing to the file system. Normally all single disk issues are solved by creating a disk image. If the HDD or SSD sustained too much damage, you'll need to send it to some hardware recovery service. RAID disks should be reconstructed by RAID Wizard as described in the corresponding chapter.
VMFS
One of the most annoying features of VMFS is that it doesn't have a proper journal and it wipes all records about file location from the file system contents during the "Delete" operation. Such a behavior is common for vSphere and VMware disk drivers. This leaves the information on the disk, but because of fragmentation often it can not read properly.
We had to develop a specific algorithm to recover such data, its results can be found in the virtual folder “Fragments of PBC". It is recommended to search this folder with the Search box and try mounting files with a size of lost VMDK. If the size of some files is similar to the size of the lost VMDK file, it is worth checking it. Keep in mind that most value is stored inside VMDK files, so even if VMDK is corrupt, there is a decent chance to get data within it intact.
Files used by VMWare virtual machines
Below is a list of files typically used by a VMware virtual machine:
VMFS 6
Note: Not all of these files will be visible in the standard vSphere browser, as it combines the VM.vmdk and VM-flat.vmdk into a single VM.vmdk file. To view all the files, you'll need to use an SSH client or VMFS Recovery™.
- vm3.vmx – This is the primary configuration file for the virtual machine. It stores all setup and configuration data.
- vm3.vmsd – An XML-type file that stores information about snapshots, including their order and how they are linked. It's worth noting that a *.vmsd file can be replaced with one from another VM or clone. Any VM with snapshots will have a *.vmsd file. Conversely, a VM with only a single *.vmdk won't have this file. If lost, it can be replaced by a similar file from a new VM with matching parameters.
- vm3.nvram – This file stores the VM's BIOS settings.
- vm3.vmdk – This is the virtual disk descriptor file for VM3-flat.vmdk.
- vm3-flat.vmdk – The virtual disk file containing all user data stored by the VM. Our software can treat these files as disk images, unlike VMware's tools, which require additional files for access.
- vm3-000001.vmdk – A descriptor for the VM-000001-delta.vmdk file.
- vm3-000001-sesparse.vmdk – Contains snapshot1 disk data. During VM operation, it's merged with VM-flat.vmdk to represent the virtual machine’s disk.
- vm3-000002.vmdk – A descriptor for VM-000002-delta.vmdk.
- vm3-000002-sesparse.vmdk – Stores disk data for snapshot2. During VM operation, it's combined with VM-flat.vmdk and VM-000001-delta.vmdk to represent the VM’s disk. Note that no changes are made to VM-flat.vmdk or VM-000001-delta.vmdk; all new data is stored in VM-000002-delta.vmdk. This means that any edits or deletions of data in VM-flat.vmdk or VM-000001-delta.vmdk are not directly executed. Instead, changes are saved as new data in VM-000002-delta.vmdk.
- vm3-Snapshot1.vmsn – Stores binary data related to snapshot1.
- vm3-Snapshot2.vmsn – Stores binary data related to snapshot2.
- vmware.log – The log file for the virtual machine.
VMFS 5
Note: Not all files will be visible in the standard vSphere browser, as it combines VM.vmdk and VM-flat.vmdk into a single VM.vmdk file. To view all files, you’ll need to use an SSH client or VMFS Recovery™.
- vm1.vmx – The main configuration file of the virtual machine, storing all setup and configuration data.
- vm1.vmsd – An XML-type file that contains snapshot information, including their order and relationships. It can be replaced by a similar file from another VM or clone. Any VM with snapshots will have a *.vmsd file. A VM with only one *.vmdk will not. If lost, it can be recreated using a similar file from a new VM with the same parameters.
- vm1.nvram – Stores the VM's BIOS settings.
- vm1.vmdk – The virtual disk descriptor file for vm1-flat.vmdk.
- vm1-flat.vmdk – The virtual disk file that contains all user data for the VM. Our software can treat these files as disk images and, unlike VMware's tools, does not require additional files to access them.
- vm1-000001.vmdk – Descriptor for vm1-000001-delta.vmdk.
- vm1-000001-delta.vmdk – Contains snapshot1 disk data. During VM operation, it is combined with vm1-flat.vmdk to represent the VM’s disk.
- vm1-000002.vmdk – Descriptor for vm1-000002-delta.vmdk.
- vm1-000002-delta.vmdk – Contains snapshot2 disk data. During VM operation, it is combined with vm1-flat.vmdk and vm1-000001-delta.vmdk to represent the VM’s disk. Note: no changes are made to vm1-flat.vmdk or vm1-000001-delta.vmdk. All new data is stored in vm1-000002-delta.vmdk, meaning edits or deletions of data in the earlier files are saved as new data in vm1-000002-delta.vmdk.
- vm1-Snapshot1.vmsn – Contains binary data for snapshot1.
- vm1-Snapshot2.vmsn – Contains binary data for snapshot2.
- vmware.log – The log file for the virtual machine.
Mounting a snapshot
Please note: we don't mount a single *.vmdk file we search the selected directory instead and build a tree with all dependencies for all *.vmdk files. So if you need to mount a VM that has snapshots, you should place all of them into a single folder so VMFS Recovery™ would be able to detect them all.
All bold VM names at the root are virtual machines. All snapshots that belong to some virtual machine are placed inside its tree.
After VMDK files are mounted they will be marked red.
It's important to mention that all available partitions from *.vmdk files will be placed into the “Hard Disk Drives" section. On the screenshot, it's “FAT32 Volume 1 (No Name)". If the partition table inside VMDK is damaged or not mapped, you won't see any partitions in this section. In this case, you'll need to scan some disks from the “Container" or “Unallocated space" sections. Please choose the most recent snapshot to scan, as selecting the original VMDK would display only the data stored inside it without the addition of more recent snapshots.
NFS
Network File System (NFS) is a distributed file system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access files over a computer network much like local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call (ONC RPC) system. By its nature, NFS is very close(yet incompatible) with Samba (SMB) or other network protocols.
Despite its name NFS is not a disk file system and it has nothing to do with disk data storage. Instead, it uses a common file system to actually store data on the disk. This could be EXT, NTFS, or any other file system. NFS doesn't allow direct disk access nor allows access to disk sectors. Unlike remote datastores, which FiberChannel, SAN, or iSCSI allows to create, NFS allows only file-level access.
Therefore, to recover data from the datastore saved on NFS, you need to extract HDDs from the NFS file server and connect them to a Windows PC. Open connected disks in the "Uneraser" mode and search for the required VMDK file. Use the "Mount disk" command if you are not a registered customer to preview if data recovered correctly, or Use "Save Wizard" to save recovered data.