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 which is not supported by Windows.
Please note: before recovering file system data, you need to make sure that disk is ok. If you suspect there is some problem with a disk(such a bad blocks, damaged or corrupt RAID configuration) you need to solve disk problem first, before continue to the file system. Normally all single disk issues are solved by creating a disk image. If 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 corresponding chapter.
One of most annoying features of VMFS is that it doesn't have a proper journal and it actually wipes all records about file location from the file system contents during “Delete" operation. Such a behavior is common for vSphere and vmware disk driver. 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, it's results can be found at the virtual folder “Fragments of PBC". It is recommended to search this folder with Search box and try mounting files with a size of lost VMDK. If size of some file is similar to the size of lost VMDK file, it is worth to check it. Keep in mind that most value stored inside VMDK files, so even VMDK is corrupt, there is a decent chance to get data withing it intact.
Here is a list of files normally used by in VmWare virtual machine:
However you won't see all of them in standard vSphere browser. It compacts VM.vmdk and VM-flat.vmdk into single VM.vmdk file. To browse all files you'll have to use SSH client or VMFS Recovery.
- Virtual Machine #1.vmx is a main file of virtual machine. All configuration and set up data stored here.
- Virtual Machine #1.vmsd file. It's a xml type file that contains information about snapshots, their order and how they are bound together. It's useful to know that *.vmsd can not be replaced by similar file pulled from another VM or it's clone. Any Virtual Machine that uses snapshot will posses a *.vmsd file in it's folder. On the contrary VM that consists of single *.vmdk will not have such file. If lost, can be replaced by a same file from a new virtual machine that have same parameters as predecessor.
- Virtual Machine #1.nvram – additional RAM file of VM.
- Virtual Machine #1.vmdk - Virtual Disk Descriptor file for Virtual Machine #1-flat.vmdk
- Virtual Machine #1-flat.vmdk – virtual disk file. Contains all the user data that VM stores. Our software is able to treat these files as a disk image and unlike vmware's won't require any other files to access it.
- Virtual Machine #1-000001.vmdk - descriptor for VM-000001-delta.vmdk
- Virtual Machine #1-000001-delta.vmdk – disk data for snapshot1. During operation of VM it's combined with VM-flat.vmdk to represent a disk in virtual machine.
- Virtual Machine #1-000002.vmdk - descriptor for VM-000001-delta.vmdk
- Virtual Machine #1-000002-delta.vmdk - disk data for snapshot2. During operation of VM it's combined with VM-flat.vmdk and VM-000001-delta.vmdk to represent a disk in virtual machine. Please note: no changes are made for VM-flat.vmdk and VM-000001-delta.vmdk. All new data is added to VM-000002-delta.vmdk. In other words all edit or delete operations of the data stored in VM-flat.vmdk and VM-000001-delta.vmdk are not actually executed. All changes over previous data will be saved and reflected in VM-000002-delta.vmdk as it would be a new data.
- Virtual Machine #1-Snapshot1.vmsn – some additional data for snapshots. Contains binary data.
- Virtual Machine #1-Snapshot2.vmsn - some additional data for snapshots. Contains binary data.
- vmware.log – log file
Please note: we don't mount a single *.vmdk file we search selected directory instead and build a tree with all dependences for all *.vmdk files. So if you need to mount a VM that have snapshots, you should place all of them into 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 it's tree.
After vmdk files are mounted they will be marked red.
It's important to mention that all available partition from *.vmdk files will be placed into “Hard Disk Drives" section. On the screenshot it's “FAT32 Volume 1 (No Name)". If partition table inside vmdk is damaged or not mapped, you won't see any partitions at this section. At this case you'll need to scan some disk from “Container" or “Unallocated space"sections. Please choose the most recent snapshot to scan, as selecting original vmdk would display only the data stored inside it without addition of more recent snapshots.
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 it's nature NFS is very close(yet incompatible) with Samba (SMB) or other network protocols.
Despite it's name NFS is not a disk file system and it has nothing to do to with disk data storage. Instead it uses a common file systems to actually store data on the disk. This could be EXT, NTFS or any other file system. NFS doesn't allows direct disk access nor allows access to disk's sectors. Unlike remote datastores, which Fiberchannel, SAN or iSCSI allows to create, NFS allows only file level access.
Therefore, to recover data from datastore saved on NFS, you need to extract HDDs from NFS file server and connect them to Windows PC. Open connected disks in "Uneraser" mode and search for required vmdk file. Use "Mount disk" command if you are not registered customer to preview if data recovered correctly, or Use "Save Wizard" to save recovered data.