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 / ESXi datastore and VMFS recovery

VMFS 5 · VMFS 6 · header · heartbeat · resource files · inactive · resignature · LUN · iSCSI · FC

ESXi datastore and VMFS recovery. A datastore that will not mount has usually lost its map, not its files; the map is rebuilt on a copy.

A VMFS datastore keeps its description of itself in a small set of metadata structures: a volume header that identifies it, a heartbeat region that hosts use to lock files, and resource files that record which blocks belong to which file. Damage to any of these, from a power loss during a write, a stalled rebuild, a controller that wrote stale data, or a partition table change on the LUN, leaves a volume whose files are whole but which ESXi will not mount, shows as inactive, reports an invalid argument from vmkfstools, or offers to mount as a snapshot. The common fixes applied in place, a resignature, a reformat, a rebuild of the array underneath, each risk the files the metadata describes. We repair the metadata on a virtual copy instead: the members are imaged, the set is reassembled in software, and the VMFS structures are read and rebuilt on that copy, with the resource files read directly where the volume will not mount at all, so every virtual machine's files can be extracted intact. A datastore on a LUN from an iSCSI or Fibre Channel array is handled the same way, from images of the array's drives or of the LUN. A set of two to four members is £500 + VAT upwards; larger sets and SAN volumes 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.

Datastore symptoms, and how long each gives you.

Not listed? Describe it on the form →
The datastore shows inactive after a reboot, with the LUN still visibleThe VMFS header or heartbeat is damaged; the files are wholeDo not delay
ESXi offers to mount the volume as a snapshot, or asks to resignature itThe volume's signature no longer matches the LUN it is on, usually after a partition table or array changeEveryday job
vmkfstools reports an invalid argument, or the volume lists as unknownThe header is unreadable; the resource files may still be intactDo not delay
The datastore was reformatted, or re-created by mistakeThe new header overwrote the old; the file blocks remain until reusedDo not delay
The array under the datastore is degraded or rebuildingThe volume is changing beneath the file system; a second failure takes bothDo not delay
The LUN disappeared from the storage array after a firmware updateThe array's own configuration lost the volume; the data is on its drivesDo 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.

The VMFS structures, and how each is recovered.

The volume headerIdentifies the volume, its version, its UUID and its block size. A damaged header is why a datastore will not mount at all. It is rebuilt on the virtual copy from the surviving structures and the partition geometry.
The heartbeat regionHosts take locks on files by writing to a heartbeat region. A host that died mid-write, or a stalled rebuild, can leave it inconsistent, and the datastore refuses to come up cleanly. It is cleared and rebuilt on the copy, never on the live volume.
The resource filesHidden files that record which blocks make up each file and each directory. Where the volume will not mount, they are read directly from the image, which gives every virtual machine's files without needing the volume to mount at all.
Reformatted and deleted datastoresA reformat writes a new header and fresh resource files but does not zero the old blocks. The old files are found from the previous structures where they survive, and carved as large contiguous files where they do not.

What the message means on the datastore.

Describe yours to us →
What you see The usual reason Where that leaves you
Datastore inactiveHeader or heartbeat damaged; or the volume beneath changedRepaired on the reassembled virtual volume
Mount as snapshot or resignature requiredVolume signature no longer matches the deviceRead from the images; nothing resignatured in place
Invalid argument, or unknown volume typeHeader unreadableResource files read directly; files extracted
Datastore empty after a reformatNew structures over old blocksOld structures recovered or files carved
LUN missing from the arrayStorage array configuration lostThe array's drives imaged and the LUN reassembled

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

The set is reassembled from the member images, order and stripe from the metadata or from the parity. On the virtual volume the VMFS header is checked and rebuilt, the heartbeat region cleared on the copy, and the resource files read; every virtual machine's files are then listed and extracted, with any snapshot chains consolidated on the extracted copies.

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

  • Do not resignature or reformat a datastore that will not mount. Both write new metadata over the old; the first makes recovery longer, the second makes it partial.
  • Do not rebuild the array underneath a sick datastore. A datastore that is already inactive is the symptom; the rebuild is what removes the data.
  • Send every member, and tell us the LUN layout where the datastore sits on a SAN; a LUN spread over several drive groups needs all of them.

Three metadata structures, the header, the heartbeat and the resource files, decide whether a VMFS volume mounts; the files they describe are usually whole.

One job, followed all the way through.

UK · RAR-2026-0671JOB LOGGED ✓

A single ESXi 6.7 host on a ProLiant DL380 with Smart Array P408i, RAID 5 of five, the VMFS 6 datastore inactive after a power cut, the array itself optimal, four machines including the firm's file server

Five drives came in labelled. All five imaged cleanly, so the set reassembled first time from the Smart Array metadata. The VMFS header was intact but the heartbeat region held a half-written entry from the moment of the power cut, which was why the host would not mount it. On the virtual copy the heartbeat was cleared and the volume mounted; the four machines were extracted, the file server's guest opened and checked, and the lot went back on a new drive ready to register. A short job, because nobody had rebuilt anything.

100% of the datastore recovered5 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
  • Note what the host said: inactive, snapshot, invalid argument
  • Send every member, and the LUN layout for a SAN

What sets us back

  • Resignaturing or reformatting the datastore
  • Rebuilding the array underneath it
  • Running a repair tool on the live volume
  • Creating a new datastore on the same LUN

Questions answered before you commit.

ESXi offers to resignature the datastore. Should I?

Not on a datastore you need the contents of. Resignaturing writes a new signature over the old, and if the volume is also damaged it can make recovery longer. Image the members first; the volume can be read from the images regardless of its signature.

The datastore is inactive but the array shows optimal. Why?

Because the fault is in the VMFS metadata, usually the heartbeat region or the header, after a power loss or a crash mid-write. The array is fine and the files are whole; the file system's map needs repairing, which is done on a copy.

We reformatted the datastore by mistake. Is the data gone?

Usually not, if nothing has been written since. A reformat writes new metadata but does not zero the old blocks, and the old files are found from the previous structures or carved as large contiguous files. Power down now.

Our datastore is on an iSCSI SAN. Can you still help?

Yes. The LUN is reassembled from images of the array's drives, or from an image of the LUN itself, and the VMFS on it repaired the same way. Tell us the array model and the LUN layout; a LUN spread over several drive groups needs all of them.

What does it cost?

A set of two to four members is £500 + VAT upwards; larger sets and SAN volumes 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.

VMware data recovery →Virtual machine, VMDK and snapshot chain recovery →RAID 5 data recovery →How a RAID array is rebuilt from member images →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