VMware ESXi, vSphere & Hyper-V Data Recovery

VMFS (Virtual Machine File System) is VMware's proprietary file system for ESXi datastores. A power cut, RAID controller failure or firmware error can corrupt VMFS metadata, leaving the datastore inaccessible. VMDKs may be intact at the block level even though VMFS cannot list them.

Deleting a flat VMDK (the VM's data file) from the datastore browser or via SSH does not immediately erase the data: it marks the space as free in VMFS. If that space has not been written over, recovery is viable by analysing VMFS internal structures to locate the deleted file's extents.

VMware snapshots create delta files (-delta.vmdk or -sesparse.vmdk) that record changes since the snapshot. A failed consolidation (merging the delta with the base disk) can leave the snapshot chain broken: the base disk and deltas become inconsistent. The VM does not boot and vCenter shows «Needs consolidation» without being able to complete it.

The datastore appears as «inactive» or «inaccessible» in vCenter/ESXi. Can be caused by underlying RAID failure, GPT partition table corruption, SAN LUN loss (path failure) or VMFS-L (locking layer) metadata corruption. VM data remains on the physical disks.

ESXi stores its boot image on a small partition (USB, SD card or local disk). If ESXi won't boot (Purple Screen of Death, bootbank corruption), the VMFS datastores on the data disks remain intact. Reinstalling ESXi on new media and re-presenting the datastores usually restores access, but requires care to avoid reformatting.

vSAN distributes VM objects across disk groups on multiple hosts. A disk group failure (damaged SSD cache disk, failed capacity disk) can leave objects «absent» or «degraded». If the FTT (Failures to Tolerate) policy is exceeded, the VM becomes inaccessible. Reconstruction requires direct access to each host's disks.

Hyper-V VHDX disks can become corrupted by power cut during write operations, CSV (Cluster Shared Volumes) failure in a cluster, or an error during a checkpoint (Hyper-V snapshot). The VM won't boot and shows an error mounting the VHDX. Repairing the VHDX structure and extracting data from the internal filesystem (NTFS/ReFS) is feasible.

Ransomware groups (Royal, BlackCat, LockBit) attack ESXi directly via SSH or known vulnerabilities (CVE-2021-21974 OpenSLP). They encrypt all VM VMDKs. Recovery depends on whether encryption completed, whether prior snapshots exist in the datastore and whether the underlying RAID has residual data.

Bit-for-bit image of each server disk (SAS, SATA, NVMe) with DeepSpar Disk Imager. If storage is a SAN, we extract the disks from the enclosure. If local storage, we clone directly. We never work on original disks.

If the server uses hardware or software RAID, we virtually reconstruct the array on the cloned images. We determine the geometry (stripe size, parity, order) from controller metadata or pattern analysis.

Mounting the VMFS volume (ESXi), NTFS/ReFS/CSV (Hyper-V) or ZFS/LVM (Proxmox) on the reconstructed array. Locating VMDK/VHDX/QCOW2 files and verifying snapshot chain integrity if applicable.

Mounting the VMDK/VHDX as a virtual disk to access the VM's internal filesystem (NTFS, EXT4, XFS). Extraction of files, databases, configurations. If the VM is not mountable, we perform block-level carving within the virtual disk.

Data delivered on an external drive or, if required, as a functional VMDK/VHDX ready to import into a new hypervisor. Detailed technical report with checksums. You only pay if we recover your data.