Taking work now — the first look is freeWhole sets posted in from anywhere in the UK, or handed in at ten drop-off pointsQuicker still, give us a ring:0800 6890668
RARRAID Array Data Recovery 0800 6890668 Price my job
RAR / Controllers and hosts / VMware VMFS and vSAN

VMFS 5 · VMFS 6 · datastore · VMDK · -flat · -delta · snapshot chain · vSAN · disk group · object · component · ESXi 6.7 · 7 · 8

VMware VMFS and vSAN recovery. A datastore on an array, or objects across a cluster, and four layers between the drives and the files.

Most VMware hosts keep their virtual machines on a VMFS datastore on a hardware RAID volume: a PERC or a Smart Array underneath, VMFS 5 or 6 on top, and each virtual machine's disks as -flat.vmdk files with -delta files for snapshots. vSAN replaces the array with objects spread as components across the cluster's disk groups, one cache and several capacity devices per host, placed by policy. When the array fails, the datastore goes with it; when a disk group fails, its components do; and in both cases the recovery has four layers: the array or the disk groups reassembled from images, the VMFS volume or the vSAN objects opened on the result, each VMDK extracted whole with its snapshot chain, and the guest's own file system opened inside it. The vSAN states are on their own page; this page is about the platform and the layers. A datastore's array of two to four members is £500 + VAT upwards after the free look, fixed in writing; vSAN and larger sets from £1,250 + VAT.

Free first lookOne fixed figure in writingNo data, no bill on most jobsReturn postage paid

Rather talk it through? An engineer answers the bench line
0800 6890668

Power down. Label every slot before a drive comes out. Do not rebuild, do not force a drive online, do not import or clear a foreign configuration, do not initialise, and do not run chkdsk, fsck, zpool import -F or mdadm --create on the members. A rebuild reads every sector of every survivor and writes to the replacement; each of the commands writes to the drives. On images, all of them are reversible. On the originals, none of them is.

Models and versions we see.

Which level is it →
Family Models or versions Metadata, defaults and notes
VMFS on internal RAIDESXi on PERC, Smart Array, MegaRAIDThe array first; then the datastore
VMFS on shared storageMSA, ME4, VNX, Unity over iSCSI or FCThe array's own page; then VMFS
vSAN OSA6.x, 7.x, 8.x with cache and capacity tiersDisk groups imaged; objects reassembled
vSAN ESA8.x on NVMe, single tierStorage pool imaged; objects reassembled
Snapshots-delta, -sesparse chainsExtracted in order; consolidated on copies

What tends to go wrong on VMware.

Four layersThe array is reassembled from images; VMFS is opened read-only on the virtual volume, its resource files and file descriptors read; each VMDK is extracted whole, descriptor and extents and every -delta in the chain; the guest's NTFS, ext4 or XFS is opened inside the extracted disk. Each layer is a place the recovery can be partial, and the file list says which.
VMFS after power lossVMFS keeps a heartbeat region and journals its metadata; a power cut mid-write can leave a datastore ESXi reports as inaccessible with every VMDK intact. It is opened on images with the journal replayed, and vmkfstools is not run on the originals.
Snapshot chainsA virtual machine with snapshots reads through a chain of -delta files back to the base disk. A missing or damaged link breaks every disk after it; a consolidation interrupted by an array fault leaves two versions of the chain. The bench extracts the chain in order and consolidates on copies.
vSAN disk groupsA failed cache device takes its whole disk group's components down; a failed capacity device takes the components on it. Broadcom's KB 326929 defines Inaccessible as an object with more failures than it was configured to tolerate. The devices are imaged by host and slot and the objects reassembled from the components on them.

VMware VMFS and vSAN symptoms, and how long each gives you.

Not listed? Describe it on the form →
Datastore or volume offline; array shows a faultStart with the array. Power down; image the members.Do not delay
Array healthy; datastore inaccessibleThe volume on top. Do not repair it on the originals.Everyday job
Guests corrupt after a rebuild or a cache lossTorn writes inside the virtual disks. Repaired on extracted copies.Everyday job
Cluster lost more nodes than it toleratesEvery affected node's disks. Do not resync.Do not delay
Packing it and posting it: power down, photograph the controller's screen or export its log, and write the slot number on each drive with a marker before it comes out of its carrier. Send every member of the set, including the one that failed first; it holds the stripes the rebuild never reached. Each drive travels in an anti-static bag inside its own padding, in a box with nothing able to move. Send the controller if it was replaced or holds an encryption key; otherwise it stays. Insure the parcel for what the data is worth, use a tracked service, and know that the posting address is not printed anywhere on this site; it arrives by email in reply to the form, with a booking sheet to print; the sheet inside the parcel is what matches it to your enquiry when it is opened. Or hand the sealed parcel in at the nearest of ten drop-off points, your name on the outside and the sheet inside; say where you are on the form and it comes by email. We pay the postage home either way. The whole of it is written up on the guide to packing and posting.

What the message means on VMware.

Describe yours to us →
What you see The usual reason Where that leaves you
Datastore inaccessible; array healthyVMFS metadata or heartbeatOpened on images; journal replayed
VM shows (inaccessible)A VMDK or its chain missingExtracted from the datastore image
Consolidation failed; disks in two chainsInterrupted by an array faultChains extracted and consolidated on copies
Array degraded on the host's controllerA member outImage the weak drives before rebuilding
Array failed; datastore or volume goneToo many members outEvery member imaged; the array, then the volume, then the guests
Datastore or CSV inaccessible; array fineThe volume layerA file-system job on the virtual volume
Virtual machine will not startA torn or missing virtual diskExtracted from the volume and repaired

From the parcel arriving to your files going back.

Work we have closed →
01

Logged the day it lands, and the first look costs nothing Free

A case number goes on the parcel and a number on every member the day it is opened, matched to the slot you wrote on it. Each member goes on the imager its interface needs, never on a controller, and its metadata is read before a sector is: the level, the order, the stripe size, the event counts that say which member is current and which dropped out first. An engineer settles what has happened to the set and how much of it can honestly be read back. Back to you come two things together: a straight note of what is liftable and what is not, plus one figure, fixed and written down. Accept it, or decline and owe us nothing.

Nothing to pay for lookingA single figure, put in writingNo rebuilds, no imports, no initialise
02

Every member imaged, including the one that failed first

Every drive in the set is imaged sector by sector, weak areas last, on hardware that controls every retry, with a map of what could not be read kept for each. Members with failed heads go to the clean bench first; that is the drive site's work and the same bench does it. The drive that dropped out first is imaged too, because it still holds every stripe written before it dropped, and a rebuild that stalled part-way never reached them.

Sector by sector, weak areas lastThe first-dropped member included
03

The geometry, from the metadata or from the parity

Where the controller's metadata survives on the members, the order, stripe size, parity rotation and data offset are read from it. Where it was cleared or overwritten, they are recovered from the data: parity across the members at the same offset should XOR to zero on a consistent stripe, which confirms the level and finds the stale member; where parity lands says the rotation; entropy at stripe edges and the file system's own anchors give the stripe size, the order and the start.

Metadata first, parity secondOrder, stripe, rotation, offset
04

Assembled in software, and repaired on the virtual volume

The set is put together from the images in software, with nothing written to any of them: the current members in, the stale member used only to fill holes a survivor could not give. The file system is checked and repaired on a copy of the virtual volume, VMFS and CSV volumes opened and the virtual machines' disks extracted, databases repaired where they need it. The originals are not touched again.

Nothing written to the imagesVirtual machines and databases opened
05

You see the file list before you pay

What was recovered is listed for you first, and only then does a bill exist. Approve the list and it is invoiced; turn it down and it is not — and where nothing has come back, most jobs carry no charge at all. Recovered data travels home on fresh media bought in for your job, with the postage at our end. Your case is not closed until you have opened the files on a machine of your own.

No charge until you accept the figureFresh media, supplied with the job5–10 days at the bench

From the bench

  • The array first. Every member imaged before vmkfstools, a rescan or a repair touches the datastore.
  • Say which virtual machines matter. Extraction begins there, and a database server's disks are checked inside.
  • Send every device from every affected vSAN disk group, labelled by host and slot, cache device included.
  • Four layers: the array, the volume, the virtual disk, the guest. Each is opened in turn on the images, and each is a place a rival's page is silent.
  • Do not let the hypervisor repair anything until the array is imaged. Its repair reads the survivors under load.
  • Say which virtual machines matter. Extraction begins there.

One job, followed all the way through.

UK · RAR-2026-0633JOB LOGGED ✓

An ESXi 7 host on a PERC H730 whose RAID 5 datastore went Failed when a second drive dropped during a rebuild, holding nine virtual machines including a domain controller and a SQL Server

All six drives came in. The set was reassembled from the images with the first-dropped drive's stripes filling what the rebuild had not reached; the VMFS 6 volume was opened read-only on the virtual array and its journal replayed; the nine VMDKs were extracted with their snapshot chains, consolidated on copies, and each guest's file system opened and checked. The SQL Server's database was recovered from its log inside its extracted disk. The nine machines were returned as OVF exports on fresh media.

100% of the datastore recovered11 days here, and back by post
Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

  • Export the array log and the hypervisor's view of the storage
  • Power down and label every member by host and slot
  • Send every member of every affected array or disk group
  • Tell us which virtual machines or databases matter most

What sets us back

  • Rebuilding the array with a weak survivor
  • Running the hypervisor's repair or migration on a degraded store
  • Formatting or re-adding a datastore
  • Restoring a backup over the only copy

Questions answered before you commit.

The array under my datastore failed. Can the virtual machines be recovered?

Usually. The array is reassembled from images, the VMFS volume opened on the result, each VMDK extracted with its snapshot chain, and each guest's file system checked inside. The virtual machines go back as exports.

ESXi says the datastore is inaccessible but the array is fine. What happened?

Usually VMFS metadata or the heartbeat region after a power cut. It is opened on images with the journal replayed; vmkfstools is not run on the originals.

My vSAN objects are inaccessible. What do I send?

Every device from every affected disk group, labelled by host and slot, cache device included, and the vSAN health and object lists. The vSAN page has the states.

What does it cost?

A datastore's array of two to four members is £500 + VAT upwards after the free look; vSAN and larger sets from £1,250 + VAT, fixed in writing.

Begin here if yours is doing the same thing.

VMware data recovery, the full job →vSAN: object inaccessible, reduced availability →Hyper-V CSV and Storage Spaces Direct →Dell PERC →RAID 5 →

Nothing gets worse while it is powered down.

Looking at it is free. Back comes a list of what opened and what did not, together with a single price to finish, set down in writing while you are still free to say no. On most jobs an invoice only follows the data. Until that list reaches you, leave the server off and the drives in their slots.

0800 6890668

Price my jobPacking and posting