Open, and work is coming in · weekdays, 9am–5:30pm Faster by phone: 0800 6890668
PDR Plymouth Data Recovery 0800 6890668 Get a price
PDR / The jobs we take in / Virtual servers and VM disks

Specialist work · virtual servers

Virtual server recovery, Plymouth. A virtual disk is only a file on a volume, so two things broke, not one.

When a virtualised server stops, the fault is nearly always a layer below the guest. The VMDK or the VHDX has gone nowhere; the datastore or the RAID set carrying it has. Which is why these jobs run in two parts. Every member of the array is copied, the set is assembled over those copies, and only then is the virtual disk opened, its snapshot chain put back in order and the guest's own file system repaired. Not a byte is written to the disks you posted, and your host stays where it is. Sets reach the bench by post from across Plymouth, Devon and Cornwall.

Nothing readable? Most jobs carry no bill Free diagnosis, then one written price Boxes come to the lab from Truro, Newquay and Tavistock

You will be talking to an engineer
0800 6890668

Virtual server symptoms, and what each points to.

Yours not here? Start at the triage →
What shows upWhat that points toWhat to do
The host cannot see its datastoreThe array beneath the datastore has lost a member and gone offlineLeave it off and re-create nothing
A guest that ran slowly, then would not power onThe VMDK sits on a set that has been a member short for weeksSend every disk in the array
One disk in the shelf is clickingHeads on that member are failing, and each restart costs more of itTake it off the mains now
The snapshot chain will not consolidateA delta or its parent is missing from the folderDo not touch anything in that folder
The host offers a new datastoreThat writes a fresh file system over your VMsSay no to it
A guest with no backup anyone can findThe virtual disk is now the only copy in existenceRing first — that one goes to the front of the queue
Getting it to us: wrap it so nothing can shift, cover it for what it is worth, and post it tracked to the intake lab in Bristol. We cover the postage back. If you want an engineer to check the packing before the box is taped, ring first. It is spelled out on the contact page.

Why this is two problems stacked, not one.

Two layers, two problemsUnderneath sit the array and the datastore. Above them sit the virtual disk and whatever the guest wrote inside it. A failure at the lower level damages the upper one in ways the guest itself cannot see, so the two are worked in that order and never the other way about.
VMDK, VHDX, VHD, QCOW2VMware writes a small descriptor beside a large flat file; Hyper-V puts the lot into one VHDX with an internal log of its own; QEMU and Proxmox use QCOW2. All three can be read from a copy, and all three come apart in their own particular way when the volume under them stops.
What a snapshot chain isTaking a snapshot freezes the base disk and sends every fresh write into a delta file. Take another and a second delta goes on top. Each one is meaningless without the one below it, so the chain has to be complete and merged in the right sequence. Miss a link and the guest will not run.
What never happens hereNo re-creating a datastore, no rebuild onto a spare, no consolidating snapshots against the files you sent. Each of those is a write, and writing is what shuts doors. Your members are read once and set aside; repairs happen on copies, where a wrong turn costs an afternoon.

What happens to a drive while it is here.

Cases in the log →
01

A number on arrival, then the free diagnosis Free

Whatever arrives is booked in under a case number on the day it reaches the bench. An engineer then works out the actual fault, and that part is free. You get a plain answer on what can come off the drive and what cannot, followed by one price in writing. Nothing further happens until you have read it and agreed.

Diagnosis at no chargeA single written figureYou owe nothing yet
02

Copies first, originals untouched

Every member of the array is read behind a write blocker and copied in full before a datastore is so much as looked at. Awkward regions are taken in short passes. Nothing goes back onto the disks you sent, at any stage of the work.

Every disk imagedNo write reaches them
03

The array, then the datastore

The set is assembled over the copies and the datastore on top of that: VMFS, or NTFS and ReFS under Hyper-V, or ext4 and XFS with LVM under KVM. Once it mounts read-only the VM folders are visible again, and the virtual disks can be listed and measured.

Array assembled on copiesMounted read-only
04

Then the guests themselves

Each virtual disk gets a pass of its own. Descriptors are checked against the flat files, snapshot chains are merged in sequence from base to newest, and the file system inside the guest is repaired — all of it on copies. Guests are then powered on to prove they run.

Repaired on copiesEvery guest booted
05

You give the word, and it ships back

Thinking it over costs you nothing. Everything the drive gave up is listed for you before any invoice exists, and the bill only follows your go-ahead. Files travel back on media bought in for your job, with return carriage paid at this end, and the case stays on the bench until you confirm they open on your own computer.

You see the list and decideWritten to fresh mediaWe pay the postage home

The faults we see most

  • A guest that will not start says almost nothing — the same silence covers a datastore that will not mount, a VMDK short of its descriptor, and a snapshot chain with a link gone. Only reading the disks separates them.
  • A snapshot is not a backup and never was — it is a delta that means something only alongside its parent and every file in between. Lose one link and what remains will not merge. Deleting snapshots to free up space is how most of these arrive.
  • A dead host is often a healthy array — plenty come in where nothing at all is wrong with the disks and the trouble is a controller, a backplane or a power supply. The members are copied, the set is assembled elsewhere, and the guests boot on our own hardware.
  • Thin provisioning changes the arithmetic — a 2TB thin disk that only ever held 300GB copies quickly, while a thick one hands you 2TB to read whatever is inside it. Say which you had, because it sets the timescale more firmly than anything else on the job.

What decides these jobs: how much of the array still reads, whether the snapshot chain is whole, whether anyone re-created the datastore after it failed, and whether the guests were encrypted. An array switched off with every member present is a good place to begin. The same array after a re-create, a rebuild onto a spare and two nights of restarts is a shorter list. An encrypted datastore needs its key from you.

A job out of the casebook.

PL · PLY-2026-0857LOGGED ✓

Two guests on a RAID 5 that had been a member short since spring

It came in from an engineering firm working into the dockyard: a five-bay chassis that had run a member short since about March, with two virtual servers on the datastore. Someone had fitted a spare and begun a rebuild, and it halted on a second disk. All five members were copied, the worst of them over several passes, and the RAID 5 was assembled above those images. The datastore mounted read-only. One VMDK was whole; the other had lost blocks where the failed member's stripes fell, and a delta was missing from its snapshot chain. The base disk and the two deltas still present were merged in sequence, the guest's file system was repaired on the copy, and both machines were powered on and proved before anything travelled back.

Both members copied first2 guests back on line

Before you seal the box.

Get these done

  • Power the array down as soon as it drops offline
  • Note the host, the hypervisor and its version
  • Find any key a locked datastore was given
  • Send every member, bay numbers written on them

What to avoid

  • Re-create the datastore to see if that helps
  • Consolidate snapshots on the original files
  • Keep restarting the host and hoping
  • Rebuild onto a spare before copies are taken

Questions that come up most weeks.

The host boots but no guest will start. Why?

Because a virtual disk is only a file, and a file needs a working volume beneath it. When a datastore or a RAID set fails, the VMDK sits exactly where it always did — the volume under it has gone. Take the array off power, leave the host alone, and let the members be copied. Guests come afterwards, over the reassembled copy, where a failed attempt costs nothing.

Our VMs sat on a RAID 5. Is that two jobs or one?

Two, stacked one on the other. The array has to be assembled from copies of its members before anything can look at the datastore, and only then can the virtual disk be examined — a VMDK that lost blocks when the set failed wants a repair of its own. Priced as a single job, worked as two, and explained in that order so nothing lands on you as a surprise.

Can we just restore the guest from a snapshot?

Only where the chain behind it is whole. A snapshot copies nothing; it is a delta file that means little without its parent and every link in between. Delete, consolidate or revert while a link is missing and you write over files we would otherwise have read. Leave the folder as it stands. Where the base disk and all its deltas can be found, they are merged in the correct order on copies of them.

The host is dead. Do we need identical hardware?

No. A VMFS datastore, a Hyper-V volume or a Linux LVM set is read from copies of the disks, and none of that asks for your original host or its card. What we do want is every member of the array, marked up with its bay number, and whatever you can tell us about the guests: how many, what they ran, and which of them matters first. Encryption is the exception — a locked datastore needs its key from you.

Pages people open after this.

NAS drives → RAID 5 rebuilds → Files held by ransomware → All the media we take →

A drive that stays switched off gets no worse.

The diagnosis is free, and it comes back as a list: which files read, which do not, and what getting them off would take. Until then, leave the drive unplugged.

0800 6890668

Book a free look Sending it in to us