Specialist · server data recovery
Server data loss is rarely dead platters — it's state: a controller that no longer trusts its disks, an array one wrong keystroke from gone, a cache that never flushed. We reconstruct from images, controller not required, and hand back the volumes, VMs and databases the business actually runs on.
Talk it through with an engineer
01273 964902
| The situation | What it means | First move |
|---|---|---|
| Foreign Configuration Detected (Dell PERC) | The metadata on the disks no longer matches the controller's memory — a safety halt, not a death notice | Neither Import nor Clear |
| 1786 — Drive Array Recovery Needed (HP) | A rebuild is required or was interrupted | Power down and image first |
| Amber drive lights after a power event | Cache and interrupted writes — the array's order survives on the disks | Don't force drives online |
| Server boots, volume missing | Controller state or file-system damage over intact data | High recovery odds |
| RAID controller itself has died | The array's geometry lives on the members, not the card | No matching controller needed |
| The VMs or databases won't mount after 'recovery' | Files back isn't the job done — consistency is | See our VM and database pages |
Your device is logged with its own case reference the moment it arrives. An engineer assesses the fault, confirms what's actually recoverable, and you get a fixed price in writing — no diagnosis fee, no obligation, and no paid work until you say go.
Power down, label every bay, resist every prompt. Each member — including the ones marked failed — is imaged individually on hardware tools before anything is interpreted.
Level, stripe size, drive order and parity rotation are derived from the DDF or RIS evidence on the images, and the array reassembled virtually — a dead controller is an inconvenience, not a wall.
The file system on top — VMFS datastores, NTFS, ReFS, ext4, XFS — is repaired on the reconstruction, and the payloads that matter (VMs, databases, shares) verified to actually mount, not just exist.
Before you pay the recovery fee you approve a full listing of what came back. Your data returns on new media with free return postage, and the case only closes once you've confirmed everything opens on your side.
Why the two-button prompt deserves its reputation: the PERC's Import writes the imported metadata's view over the live one; Clear erases the drives' DDF mapping outright. Both are one keystroke, neither is undoable, and both become perfectly safe questions the moment every member has been imaged — which is why imaging first isn't caution here, it's the whole strategy.
Power cut, UPS exhausted, and on restart the Smart Array wanted decisions nobody could safely make. All four members imaged, the RIS metadata read, delayed parity honoured — and the practice-management database mounted from the rebuild, complete to the last pre-outage write the cache had flushed.
Usually not. Most server incidents are controller state, array metadata or file-system damage over intact disks. Power it down, stop the prompts, and the odds stay strongly in your favour.
The Dell PERC has found array metadata on the disks that doesn't match what its own memory expects — after a board swap, moved drives or a controller fault. It's a safety pause. Both on-screen answers can destroy data; imaging first makes the question safe.
Yes. PERC and MegaRAID write standard DDF metadata to each member, HP writes its RIS blocks — the geometry travels on the drives. We reconstruct from images on the bench, no matching card required.
Both — and the distinction matters. Getting a VMDK or MDF file back is half the job; making the hypervisor or database engine accept it is the other half. Our VMware and database pages cover exactly that layer.
Every restart of a damaged device costs data. Open a case first — the diagnosis is free either way.