Specialist · server data recovery
Most dead servers still hold healthy disks. What breaks is the state around them — a RAID card at odds with its own metadata, a prompt where one wrong answer finishes the array, cached writes that never landed. Working from images, with no need for the original controller, we put back the volumes, databases and virtual machines an Exeter business actually runs on.
Talk it over with an engineer
0800 6890668
| What's wrong | What it usually means | Step one |
|---|---|---|
| Foreign Configuration Detected on a Dell PERC | Disk metadata and the card’s memory no longer agree; the controller has stopped to be safe, not because data has gone | Decline both prompts |
| 1786 — Drive Array Recovery Needed (HP) | A queued rebuild, or one that died halfway through | Power down; image every disk first |
| Power cut, and now the bays glow amber | Writes caught mid-flight and a cache in doubt — the array’s layout is still on the disks | Force nothing back online |
| Boots fine, but the data volume is missing | Damage sits in controller state or the file system; the data below it survives | Strong odds of recovery |
| The controller card itself is dead | Stripe map, disk order, parity rotation — every one of them written to the member disks | A matching card isn't needed |
| Files restored, yet nothing mounts — VMs, databases | Recovered isn’t the same as consistent — and consistency is the test | Covered on our VMware and database pages |
Your device is logged under its own case number the day it arrives. An engineer finds the fault, tells you plainly what stands a real chance of coming back, and writes you one fixed quote. Nothing is charged for that look, nothing obliges you, and paid work starts only when you say so.
Power off, label every disk with its bay number, and answer no prompts. Each member is then imaged on its own on dedicated equipment — including any the controller flagged as dead — before we interpret a single byte.
Those images hold the DDF or RIS records, and it's these that carry the level, the stripe size, the disk order and — for RAID 5 and 6 — the parity rotation. From there the array is rebuilt virtually; losing the original card is no loss at all.
On the rebuilt copy we repair whatever sits on top — NTFS or ReFS, a VMFS datastore, ext4 or XFS — then test what actually counts: guests boot, databases attach cleanly, shares open.
Before any fee falls due you see a full listing of everything recovered and approve it. Your files travel back on brand-new media, return postage on us, and the case stays open until you've confirmed everything opens on your own machine.
What Import and Clear actually do: Import forces the foreign metadata’s version of events onto the running configuration; Clear erases the DDF map from every member for good. Each is a single keypress, neither offers a way back — and once the disks exist as images, neither can hurt you. That is why imaging comes first: not caution, the whole strategy.
A power cut outlasted the UPS, and when the server came back the Smart Array asked questions no one could safely answer. We imaged all four members, parsed the RIS metadata and honoured the delayed parity — then mounted the practice-management database from the rebuild, intact to the final write the cache had flushed before the lights went out.
Not as a rule. Most of the time it's controller state, array metadata or file-system damage, all sitting on disks that are physically fine. Power it down, don't click through any prompts, and the odds stay well on your side.
Your Dell PERC has found disk metadata that disagrees with what it remembers — typical after swapped boards, shuffled drives or a controller fault. Stopping is deliberate caution. Both choices on that screen can destroy data; take images first and neither one can hurt you.
Yes. The layout travels on the disks themselves — PERC and MegaRAID write standard DDF metadata, HP writes RIS blocks. We rebuild from images on the bench, so an identical controller is never required.
Both, and it's a distinction worth making. Getting a VMDK or MDF back is half the job; coaxing the hypervisor or database engine into mounting it is the other half — the layer our VMware and database pages cover.
Each power-up of a failing device takes more data with it. Open a case first — the look-over is free whichever way it goes.