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. Virtual disks are only files on a volume, so two things failed, not one.

When a virtualised server stops, the fault is nearly always in the layer below the guest. The VMDK or VHDX went nowhere; the datastore or RAID set that carried it did. So we do these jobs in two separate stages. Every member of the array is copied, the set is rebuilt over those copies, and only after that is the virtual disk opened, its snapshot chain restored and the guest's file system repaired. Nothing is ever written to the disks you posted, and your host stays where it is. Sets reach the bench by post from around 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 turns upWhat that points toWhere to start
The host cannot see its datastoreThe RAID set holding the datastore has lost a member and gone offlineLeave it off and re-create nothing
A guest that ran slowly, then would not bootThe VMDK sits on an array that has been a member short for weeksSend every disk in the array
One disk in the shelf is clickingHead failure on that member continues, 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 leftCall us first: this job gets priority in our queue
Getting it to us: once you receive your quote, wrap it securely so it cannot shift in transit, insure it for its value, and send it tracked to the intake lab in Bristol. We cover the return postage. If you want an engineer to check the packing before the box is taped shut, contact us before sending. Details are on our contact page.

Why this is two problems stacked, not one.

Two layers, two problemsAt the bottom of the stack are the array and the datastore. On top of both are the virtual disk and whatever the guest has written to it. A failure at the lower layer damages the layers above in ways the guest does not know about. For this reason, the work goes from the lowest layer to the highest, and never the other way round.
VMDK, VHDX, VHD, QCOW2VMware writes a small descriptor beside a large flat file. Hyper-V puts everything, including a log of its own, into a single VHDX. QEMU and Proxmox use QCOW2. All three can be read from a copy, but each comes apart in its own way when the volume under it stops.
What a snapshot chain isWhen a snapshot is taken, the base disk is frozen and all new writes go to a delta file. Take a second snapshot and another delta file goes on top. Each one is meaningless without the one below it, so the chain has to be intact and merged in sequential order. If a link is missing, the guest will not run.
What never happens hereNone of the following is done here: re-creating the datastore, rebuilding onto a spare, consolidating snapshots against the files you sent. Each would mean a write to the disks holding the data, and writing is what closes off access to your data. Your members are read once and set aside. Any repair is done on the copy, where a wrong turn costs an afternoon.

What happens to a drive while it is here.

01

A number on arrival, then the free diagnosis Free

Whatever is delivered is booked in using a unique reference (case number) on the date it arrives at the bench. The engineer will identify the actual fault at no charge. This gives a straightforward answer on what can be recovered from the drive and what cannot, plus one written quotation. There will be no further activity until you have read and accepted the quotation.

Diagnosis at no chargeA single written figureYou owe nothing yet
02

Copies first, originals untouched

Each disk in your array is read behind a write blocker and fully copied before the datastore is even looked at. Problem areas are read in short passes. At no point is anything written back to the disks you sent.

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 can be seen again and the virtual disks listed and measured.

Array assembled on copiesMounted read-only
04

Then the guests themselves

Each virtual disk then gets a separate pass. Descriptors are checked against their flat files, snapshot chains are merged from base to newest, and the file system inside the guest is repaired, all on copies. The guests are then powered on to prove they run.

Repaired on copiesEvery guest booted
05

You give the word, and it ships back

Give yourself time to consider it. It costs you nothing. We list all of the files we recover for you before sending out an invoice, and we only ask for payment once you have authorised it. We also buy media specifically for your recovery and send it back to you, with the return postage paid by us. The case stays here on our bench until we have your confirmation that the files open properly on your own machine.

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 missing VMDK descriptor, or a snapshot chain with a missing link. Reading the disks is what separates them.
  • A snapshot is not a backup and never was: it is simply a delta file that has meaning only alongside its parent and all the files in between. Remove one link from the chain and what's left will not merge. Deleting snapshots to reclaim space is how most of these arrive.
  • A dead host often has a healthy array: a lot of them come in with nothing wrong with the disks, and the issue is a faulty controller, a bad backplane or a failing power supply. The members are copied, the set is built elsewhere, and the guests boot on our own hardware.
  • Thin provisioning changes the arithmetic: a thin 2TB disk that never held more than 300GB copies quickly, while a thick 2TB disk means reading the full 2TB whatever is inside it. Tell us which type you had, because it gives a better idea of the timescale than anything else on the job.

What decides these jobs: how many disks in the array are still reading, whether the snapshot chain is complete, whether the datastore was re-created after it went down, and whether the guests were encrypted. If you start with an array turned off and every member present, you've got a great place to start. If the datastore was re-created, a rebuild was run onto a spare and the host restarted over two nights, the list is much shorter. And if the datastore is encrypted, you'll need to give us the key.

A job out of the casebook.

PL · PLY-2026-0857FILED ✓

Two guests on a RAID 5 running a member short since spring

It came from an engineering firm working into the dockyard: a five-bay chassis that had been running with only four members since about March, with two virtual servers on the datastore. Someone had added a spare to the array and begun a rebuild, which stopped on a second disk. All five members were copied, some of them needing several passes, and the RAID 5 was assembled above those images. The datastore then mounted read-only. The first VM 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 that remained were merged in sequence, and the guest's file system was repaired on the copy. Both machines were booted and proved before anything was sent back.

All five members copied first2 guests back on line

Before you seal the box.

Get these done

  • Turn the array off 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 really just a file, and a file needs a working volume under it. Once a datastore or RAID set fails, the VMDK stays exactly where it was, but there is no longer a volume underneath it. Turn off the array straight away, do not touch the host, and let each member be copied. The guests come afterwards, over the reassembled copy, where a failed attempt costs nothing.

Our VMs were on a RAID 5. Is that one job or two?

Two, one on top of the other. First the array must be built 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 in the RAID failure needs a repair of its own. Priced as a single job, worked as two, and explained in that order so you know what to expect.

Can we just restore the guest from a snapshot?

Only where the chain behind it is whole. A snapshot does not copy anything; it is a delta file that means little without its parent and every link in between. If you delete, consolidate or revert while a link is missing, you overwrite files we could otherwise have read. Leave the folder as it is. Where the base disk and all its deltas can be found, they are merged in the correct order on copies.

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 needs your original host or its card. We do need every member of the array, marked with its bay number, and whatever you can tell us about the guests: how many there are, what they ran, and which matters first. Encryption is the exception: a locked datastore needs its key from you.

A drive that stays switched off gets no worse.

Diagnosis costs nothing. We give you a report listing which files can be read, which cannot, and what is needed to get them off. Do not connect the drive until then.

0800 6890668