WeRecoverData

VMware vSAN Data Recovery

vSAN turns the local disks of an ESXi cluster into a shared datastore, which means there is no array to fall back on when the cluster itself is damaged. Cases usually arrive after hosts were rebuilt or removed too quickly, a disk group or storage pool failed, or virtual machines were deleted from a datastore with no backup.

Platform Lineage and Naming

VMware introduced vSAN (originally Virtual SAN) in vSphere 5.5 as a kernel-level distributed storage layer, and it became the storage foundation of VMware Cloud Foundation and VxRail-style hyperconverged systems.

vSAN 8 introduced the Express Storage Architecture (ESA) alongside the long-standing Original Storage Architecture (OSA). Both remain in production, and their on-disk formats and reconstruction paths differ materially — so a recovery starts by establishing which architecture the cluster ran and at which on-disk format version.

Generations and Models We Evaluate

Architecture and Data Layout

vSAN stores each VMDK, namespace, snapshot delta and swap file as an object. Objects are split into components distributed across hosts according to a storage policy — RAID-1 mirroring, or RAID-5/6 erasure coding — with witness components used to keep quorum. A VM is readable only when enough components and witnesses are available to form quorum for each of its objects.

In the Original Storage Architecture, each host contributes one or more disk groups, each with a dedicated cache device in front of capacity devices. Losing the cache device fails the entire disk group behind it, which is a common and often surprising cause of large-scale component loss.

The Express Storage Architecture removes the cache/capacity split: all NVMe devices in a host form a single storage pool, and each object is written through a log-structured filesystem with its own metadata. Because the layout and metadata differ from OSA, ESA reconstruction is a separate methodology rather than a variation on the same one.

Recovery is performed from images of the devices in every contributing host, reassembling components into objects, then extracting VMDKs and finally the guest file systems or databases inside them.

Logical Failures

Hardware Failures

Encryption and Keys

vSAN supports data-at-rest and data-in-transit encryption using an external key provider (KMS/KMIP) or vSphere Native Key Provider. Key material and the key provider configuration must be preserved with the devices — encrypted vSAN devices cannot be interpreted without them.

Frequently Asked Questions

Does it matter whether the cluster ran OSA or ESA?

Yes, materially. The Original Storage Architecture uses cache-plus-capacity disk groups, while the Express Storage Architecture uses single-tier NVMe storage pools with a different object layout and metadata. Identifying which one was in use is one of the first steps in the evaluation.

Several hosts are gone. Can anything be recovered?

It depends on the storage policy in force for each object. RAID-1 objects can survive host loss up to their Failures To Tolerate setting; erasure-coded objects have different tolerances. Partial recovery of a subset of VMs is a common outcome and is assessed per object.

Can we just rebuild the cluster and re-add the disks?

Rebuilding a cluster or recreating disk groups initialises devices and is one of the most damaging things that can be done after a vSAN failure. Preserve the current state and have it evaluated first.

Do you need all the hosts, or just the failed ones?

Devices from every host that contributed components to the affected objects are normally required, because components are distributed across the cluster rather than held on one host.

Related