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 / Virtual machine, VMDK and VHDX recovery

VMDK · -flat · -delta · descriptor · CID · VHDX · AVHDX · checkpoint · deleted VM · guest file system

Virtual machine, VMDK and VHDX recovery. A machine is a set of files; getting the files back is the start, and a guest that boots is the finish.

A virtual machine on disk is a small family of files. On VMware, a text descriptor names a large -flat.vmdk that holds the disk, and each snapshot adds a -delta file with its own descriptor pointing at its parent; on Hyper-V, a .vhdx holds the disk and each checkpoint adds an .avhdx differencing file chained to the one before. The machine's configuration sits beside them. Most machine-level failures are failures of the chain rather than of the data: a delta whose parent's content ID no longer matches, a differencing disk whose parent was moved, a consolidation that stopped halfway, a snapshot deleted from the wrong end. And a machine deleted from disk is not gone until its blocks are reused. We recover machines by extracting every file from the repaired datastore or volume, consolidating the chain on the extracted copies in the right order, rebuilding descriptors where they are missing, carving deleted machines from the free space, and then opening each guest, mounting its file system and checking its databases, because a virtual disk is only recovered once what is inside it works. The array or volume underneath still has to be reassembled first, so the price bands are those of the set it lives on: £500 + VAT upwards for two to four members, from £1,250 + VAT for larger sets.

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.

Machine-level symptoms, and how long each gives you.

Not listed? Describe it on the form →
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 a machine recovery involves.

Extracting the filesOnce the datastore or volume is repaired on the virtual copy, every file of the machine is extracted: the base disk, each delta or differencing disk, the descriptors and the configuration. Nothing is consolidated on the live datastore.
Consolidating the chainSnapshots and checkpoints are applied newest to oldest onto a copy of the base, each descriptor's parent and content ID checked and, where they disagree, corrected on the copy. A missing link is found by its content, not its name.
Carving deleted machinesA -flat.vmdk or a .vhdx is a large file, often contiguous, and when the datastore's entry is gone the file is found from the free space by its structure. The guest's own file system inside it confirms the carve is whole.
Opening the guestA recovered disk is mounted and its file system, NTFS, ext4, XFS, checked; SQL Server, Exchange and other databases inside are opened and verified. Only then is the machine listed as recovered, as a disk that boots.

What the message means for the machine.

Describe yours to us →
What you see The usual reason Where that leaves you
Cannot open the disk or a snapshot disk it depends onMissing or renamed chain linkChain reconstructed on extracted copies
Parent modified since the child was createdContent ID mismatchDescriptors corrected; chain consolidated
Consolidation failedA tangled or long chainApplied in order on a copy of the base
Machine deleted from diskEntries gone, blocks intactCarved from free space; guest verified
Chain of virtual hard disks is broken (Hyper-V)Differencing disk's parent moved or lostParent located by content; chain merged on a copy

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 datastore or cluster volume is repaired on the reassembled virtual volume and each machine's files listed and extracted. For each machine the chain is consolidated on a copy of its base, descriptors rebuilt where missing, and deleted machines carved from the free space. Each guest is then mounted, its file system checked and its databases opened.

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

  • Never consolidate or delete snapshots on a machine that will not start. The newest data is in the deltas, and a failed consolidation can discard it. Copies first, always.
  • A deleted machine is a race. Its blocks survive until the datastore reuses them; power the host down and nothing more will be written.
  • Tell us what is in the guests. A SQL Server or Exchange database inside a machine is checked for consistency before the machine is listed as recovered.

Newest to oldest is the only order a snapshot chain can be consolidated in; done the other way round, the most recent writes are the first thing lost.

One job, followed all the way through.

UK · RAR-2026-0674JOB LOGGED ✓

A Hyper-V 2019 host on a ThinkSystem SR650, a machine running the accounts system that would not start after a backup job left three checkpoints half-merged, the chain reported broken, on a RAID 10 of four

The four members came in and the set reassembled cleanly from the MegaRAID metadata. The machine's .vhdx and three .avhdx files were extracted from the ReFS volume; the newest checkpoint's parent pointer had been rewritten by the failed merge to a file that no longer existed. The real parent was identified by its content and the chain merged in order onto a copy of the base. The guest booted, the accounts database opened cleanly, and the machine went back as a single merged disk.

100% of the machine recovered6 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
  • Leave every snapshot and checkpoint exactly as it is
  • Note the machine's name and what it held
  • Send every member of the set it lived on

What sets us back

  • Consolidating or deleting snapshots on a dead machine
  • Editing descriptor files on the live datastore
  • Creating new machines on the same datastore
  • Rebuilding the array underneath

Questions answered before you commit.

Can you recover just one virtual machine?

Yes, once the datastore or volume it lives on is reassembled and repaired on the virtual copy. The machine's files are extracted, its chain consolidated and its guest opened, and you can have only the machines that matter. The set still has to be rebuilt first, because the files are striped across every member.

A snapshot chain is broken. Is the data lost?

Rarely. The data is in the base and the delta files; what is broken is the link between them, a parent pointer or a content ID. We find the right parent by its content, correct the descriptors on copies and consolidate the chain in order. Do not consolidate on the live datastore.

We deleted a machine from disk. Can it come back?

Usually, if nothing has been written to the datastore since. The disk file is large and often contiguous, and it is carved from the free space and then verified by opening the guest. Power down now; every write reduces what survives.

Will the recovered machine boot?

That is the standard we work to. Each guest is mounted, its file system checked and its databases opened before it is listed as recovered, so what comes back is a disk you can register and start, not a file that may or may not work.

What does it cost?

The price band is that of the set the machine lives on: £500 + VAT upwards for two to four members, from £1,250 + VAT for larger sets. The machine extraction and guest checks add to the bench time, not to the band. The first look is free.

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