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 / Servers and virtualisation / VMware data recovery

VMware · ESXi 6.7, 7, 8 · VMFS 5 and 6 · vSAN · datastore · VMDK · snapshot chain · PERC · Smart Array

VMware data recovery. The datastore is a file system on an array, and each machine is a set of files inside it; recovery runs back up those layers in order.

A VMware host keeps its virtual machines on a datastore, and a datastore is a file system, VMFS 5 or VMFS 6, on a volume, usually a hardware RAID set on a PERC, a Smart Array or a MegaRAID, sometimes an iSCSI or Fibre Channel LUN on a storage array, and on vSAN a set of objects spread as components across the disks of every host in the cluster. Each virtual machine on it is a handful of files: a small descriptor, a large -flat.vmdk holding the disk, -delta files for every snapshot, and the configuration and log files beside them. When the storage fails, the machines go with it, and the temptation to fix it in place, to rebuild the array, to resignature the datastore, to delete a snapshot that will not consolidate, is exactly what turns a recoverable failure into a lost one. We take it the other way, from the bottom up. Every member drive is imaged, the set is reassembled in software from the images, the datastore is repaired on that virtual volume, each VMDK is extracted and its chain consolidated in order, and each guest is opened and its databases checked before anything is listed as recovered. A set of two to four members is £500 + VAT upwards; larger sets, SAN LUNs and vSAN clusters start at £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.

VMware symptoms, and how long each gives you.

Not listed? Describe it on the form →
The datastore shows inactive, or will not mount after a rebootThe volume under it has changed or lost members, or the VMFS header or heartbeat region is damaged; the VMDKs are intact until something writesDo not delay
The array is degraded and a rebuild has startedEvery survivor is being read end to end; a second weak member fails the set during the rebuild more often than at any other timeDo not delay
A virtual machine will not power on: cannot open the disk, or one of the snapshot disks it depends onA link in the snapshot chain is missing or its content ID no longer matches its parent; the data is still in the filesEveryday job
A machine was deleted from disk, or a datastore was reformattedVMFS does not zero the blocks; the file data remains until the space is reused, and recovery is a race against new writesDo not delay
vSAN shows objects inaccessible or reduced availabilityComponents on failed disks or hosts are missing; the object's data may still be reconstructable from the surviving componentsDo not delay
The controller shows the virtual disk foreign, or offlineThe configuration on the members no longer matches the controller's; importing it can start a rebuild from the wrong memberDo 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 VMware adds to a RAID recovery.

VMFS metadataA VMFS volume has a header, a heartbeat region and resource files that describe every file's blocks. Damage there, from a power loss or a bad write, makes a healthy volume refuse to mount. It is repaired on the reassembled virtual volume, with the resource files read directly where the mount will not.
The VMDK and its chainA thick or thin -flat.vmdk is one large file; each snapshot adds a -delta file whose descriptor names its parent and the parent's content ID. The chain must be consolidated newest to oldest; a missing link or a mismatched ID stops it, and rebuilding the descriptor by hand is routine bench work.
Deleted machines and reformatted datastoresDeleting a machine from disk, or reformatting a datastore, removes the entries, not the blocks. The large contiguous files VMFS creates carve well, and a machine's disk can usually be recovered whole if nothing has been written since.
vSAN is a different animalvSAN keeps no datastore on an array; it keeps objects split into components across the cache and capacity disks of every host, with the layout in each disk's own metadata. Recovery means imaging every disk in the cluster, reading the component map, and reassembling each object; it is the longest VMware job there is.

What the message means on a VMware host.

Describe yours to us →
What you see The usual reason Where that leaves you
Datastore inactive or not mountedVolume lost members, or VMFS header or heartbeat damagedImaged, reassembled and repaired on the virtual volume
Cannot open the disk, or one of the snapshot disks it depends onA missing or mismatched link in the chainChain consolidated on the extracted files; descriptor rebuilt
The parent virtual disk has been modified since the child was createdContent ID mismatch between delta and parentDescriptors corrected on copies and the chain consolidated
Invalid argument from vmkfstools, or the volume shows as a snapshotVMFS signature or partition table changedRead from the images, never resignatured in place
vSAN object inaccessible, reduced availability with no rebuildComponents lost beyond the policy's toleranceEvery disk imaged; components reassembled by object

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; for vSAN, every cache and capacity disk from every host in the cluster. Members with failed heads go to the clean bench first. The first-dropped member is imaged too, because its stale copy fills holes the survivors cannot.

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

The geometry, from the metadata or from the parity

The controller's metadata on the members gives the order, stripe size and parity rotation; where it was cleared, they are recovered from the parity itself. On the reassembled virtual volume the VMFS header, heartbeat and resource files are read, the datastore repaired on a copy, and each machine's files extracted; for vSAN, the component map on each disk is read and every object reassembled from its components.

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

  • A rebuild on a VMware host is the single commonest cause of total loss we see. The survivors are read end to end, a second weak member drops, and the datastore goes with it. Power down instead.
  • Do not delete or consolidate snapshots on a machine that will not start. The delta files hold the most recent data; a failed consolidation can discard it. We consolidate the chain on extracted copies.
  • Tell us the controller model and the datastore layout if you can, and whether vSAN is in play; a vSAN job needs every disk from every host, and we will say so before you ship.

Six files make up a typical machine with one snapshot: the descriptor, the -flat, the -delta, its descriptor, the .vmx and the .vmsd. All six are recovered before the guest is opened.

One job, followed all the way through.

UK · RAR-2026-0668JOB LOGGED ✓

A two-host ESXi 7 setup on PowerEdge R740s with PERC H740P, RAID 5 of six 2.4 TB SAS, the datastore inactive after a rebuild stalled on a second failure, eleven machines including the practice's SQL Server

All seven drives came in labelled, including the part-written spare. Two members had failed heads and were imaged after head swaps; the DDF metadata gave the order and a 256K stripe; the set was reassembled in software and the VMFS 6 datastore repaired on the virtual volume, its heartbeat region having been damaged by the stalled rebuild. Eleven machines were extracted; two had snapshot chains, consolidated on the copies. Each guest opened, and the SQL databases were checked and attached cleanly. Everything came back on new drives, with the machines ready to register on a fresh datastore.

11 machines, all guests opened10 days here, and back by courier
Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

  • Power the host down and leave it down
  • Label every drive by slot before any comes out
  • Note the controller model and the datastore type
  • Send every member, including any replacement

What sets us back

  • Starting or continuing a rebuild
  • Resignaturing or reformatting the datastore
  • Deleting or consolidating snapshots on a dead machine
  • Importing a foreign configuration on the controller

Questions answered before you commit.

Can you recover the virtual machines, not just the files?

Yes. Each machine is extracted as its files, the snapshot chain consolidated, and the guest opened and checked, so what comes back is a disk you can register and boot, not a pile of blocks. Databases inside the guests are checked for consistency as well.

The datastore says inactive. Is the data gone?

Rarely. Inactive usually means the volume under it has changed, a member lost or a rebuild stalled, or the VMFS metadata is damaged. The VMDKs are intact on the members until something writes to them, which is why the first instruction is to power down and not rebuild.

Can you recover a deleted virtual machine?

Usually, if nothing has been written to the datastore since. VMFS removes the entries, not the blocks, and the large files it creates carve well. The sooner the host is powered down, the more complete the machine.

What about vSAN?

vSAN jobs need every cache and capacity disk from every host in the cluster, because objects are split into components across all of them. We read each disk's component map and reassemble every object. It is the longest VMware job, and it is quoted from £1,250 + VAT.

What does it cost?

A set of two to four members is £500 + VAT upwards; larger sets, SAN LUNs and vSAN clusters start at £1,250 + VAT. The first look is free, the figure is given in writing, and on most jobs an invoice only follows the data.

Begin here if yours is doing the same thing.

ESXi datastore and VMFS recovery →Virtual machine, VMDK and snapshot chain recovery →VMware VMFS and vSAN on the array →RAID 5 data recovery →Server data recovery →

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 then, power the host down, label every drive, and rebuild nothing.

0800 6890668

Price my jobPacking and posting