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 / Hyper-V data recovery

Hyper-V 2012 R2 to 2022 · VHDX · AVHDX · checkpoints · CSV · ReFS · NTFS · Storage Spaces Direct · PERC · MegaRAID

Hyper-V data recovery. Under a cluster shared volume there is an ordinary NTFS or ReFS volume on an array, and each machine is a VHDX and its chain.

A Hyper-V host keeps its machines as .vhdx files, with an .avhdx differencing disk for every checkpoint, on an NTFS or ReFS volume, which in a cluster is presented as a cluster shared volume. Underneath, on a standalone host, is a hardware RAID set on a PERC, a Smart Array or a MegaRAID; in a cluster it may be a LUN on a SAN, or Storage Spaces Direct pooling the drives of every node. When the storage fails, the machines fail with it, and the host's own remedies, a rebuild, a chkdsk on the volume, a merge of checkpoints, are the actions that turn a recoverable fault into a permanent one. ReFS deserves a particular word: it has no chkdsk, it repairs by discarding what it cannot verify, and a ReFS volume whose metadata is damaged is best read from an image by tools that understand its structures rather than mounted and left to decide for itself. We work from the bottom: every member imaged, the set or the storage pool reassembled in software, NTFS or ReFS repaired on the virtual volume, each VHDX extracted and its checkpoint chain merged in order on copies, and each guest opened and its databases checked. A set of two to four members is £500 + VAT upwards; larger sets, SAN LUNs and Storage Spaces Direct pools 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.

Hyper-V 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 Hyper-V adds to a RAID recovery.

VHDX structureA .vhdx holds its own metadata and a block allocation table at the start of the file, with a log for crash consistency. A VHDX cut short by a failure is repaired from its own structures on a copy, and its guest file system then checked.
Checkpoint chainsEach checkpoint is an .avhdx differencing disk whose header names its parent. Merging applies them in order onto a copy of the base; a parent lost or renamed is found by its content and the chain rebuilt, never on the live volume.
ReFS is not NTFSReFS has no chkdsk; its repair strategy is to drop what it cannot verify, which on a damaged volume can mean dropping files. We read ReFS from the image with tools that walk its structures directly, so nothing is discarded by an automatic repair.
Storage Spaces DirectThe pool spreads slabs across the drives of every node, with the map held in each drive's own metadata. Recovery means every drive from every node, imaged, and the pool reassembled from the maps; it is the longest Hyper-V job there is.

What the message means on a Hyper-V host.

Describe yours to us →
What you see The usual reason Where that leaves you
CSV offline, or volume rawArray or pool changed; NTFS or ReFS metadata damagedReassembled and repaired on the virtual volume
Chain of virtual hard disks is brokenDifferencing disk's parent moved or lostParent found by content; chain merged on a copy
Merge failed; machine will not startHalf-applied checkpointChain re-merged in order on copies
ReFS: the volume is raw, or files vanished after a repairReFS discarded what it could not verifyRead from the image before any automatic repair
Storage pool unhealthy; virtual disk detachedSlabs lost beyond resiliency; a node downEvery drive imaged; pool reassembled from the maps

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 member of the set is imaged sector by sector, weak areas last; for Storage Spaces Direct, every drive from every node. Members with failed heads go to the clean bench first, and 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 set is reassembled from the metadata or from the parity; a Storage Spaces pool is reassembled from the slab maps on each drive. On the virtual volume NTFS is repaired on a copy, and ReFS is read directly by its structures rather than mounted. Each machine's VHDX and checkpoint files are extracted, the chain merged in order on a copy of the base, and each guest opened and its databases checked.

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 run chkdsk on a cluster volume that has gone raw, and do not let ReFS repair itself; both can discard files that an image would have preserved.
  • Do not retry a failed checkpoint merge. The newest data is in the .avhdx; we merge the chain on copies, in order.
  • Storage Spaces Direct needs every drive from every node; tell us the node count and we will say what to ship before you do.

No chkdsk exists for ReFS; its automatic repair discards what it cannot verify, which is why a damaged ReFS volume is read from an image rather than mounted.

One job, followed all the way through.

UK · RAR-2026-0679JOB LOGGED ✓

A two-node Hyper-V 2019 cluster on PowerEdge R640s, the cluster shared volume on a MegaRAID RAID 6 of eight, offline after a rebuild stalled on a second failure, fourteen machines including the finance system on SQL Server

All nine drives came in, the eight members and the part-written replacement. Two members had failed heads and were imaged after head swaps; the DDF metadata gave the order and a 64K stripe, and the set reassembled in software with the stale member filling the holes. The ReFS volume beneath the CSV had lost part of its metadata to the stalled rebuild; it was read directly from the image rather than mounted, and all fourteen VHDX files were extracted, five with checkpoint chains merged in order on copies. Every guest opened, and the SQL databases attached cleanly.

14 machines, all guests opened12 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 or node down and leave it down
  • Label every drive by slot and by node
  • Note the controller or pool layout and the volume type
  • Send every member, including any replacement

What sets us back

  • Starting or continuing a rebuild
  • Running chkdsk or letting ReFS repair the volume
  • Retrying a failed checkpoint merge
  • Deleting checkpoints on a machine that will not start

Questions answered before you commit.

The cluster shared volume is offline. Are the machines gone?

Rarely. Offline usually means the array or pool beneath has changed or the NTFS or ReFS metadata is damaged, while the VHDX files are whole. The machines are recovered by reassembling the set and repairing the volume on a copy. Do not run chkdsk and do not rebuild.

Why do you treat ReFS differently?

Because ReFS has no chkdsk and repairs by discarding what it cannot verify, which on a damaged volume can mean losing files that an image would have kept. We read a damaged ReFS volume from the image with tools that walk its structures, so nothing is thrown away automatically.

A checkpoint merge failed and the machine will not start. What now?

Do not retry it. The newest data is in the .avhdx file, and a second failed merge can discard it. We extract the base and every differencing disk, find each parent by its content, and merge the chain in order on a copy.

Can you recover a Storage Spaces Direct pool?

Yes, from every drive of every node, imaged and reassembled from the slab maps each drive carries. It is the longest Hyper-V job and is quoted from £1,250 + VAT. Tell us the node count before you ship.

What does it cost?

A set of two to four members is £500 + VAT upwards; larger sets, SAN LUNs and Storage Spaces Direct pools 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.

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