Specialist work · server recovery
The disks inside a dead server are usually fine. It is everything around them that goes: a RAID controller arguing with its own metadata, a screen prompt where the wrong answer ends the array, write cache that never reached the platters. We work from images, we do not need your original card, and back come the volumes, databases and virtual machines your business depends on.
Run the problem past an engineer
0800 6890668
| The problem | What's behind it | First move |
|---|---|---|
| Dell PERC says Foreign Configuration Detected | What the disks say and what the card remembers have diverged; it halted out of caution, not because anything is lost | Pick neither option |
| 1786 — Drive Array Recovery Needed (HP) | A rebuild is pending, or one collapsed part-way | Shut it off; clone the disks first |
| After a power cut the bay lights are amber | Writes interrupted and a cache you cannot vouch for; the array map itself is still on the members | Do not force anything online |
| It boots, but the data volume has vanished | The fault lies in controller state or the file system; underneath, the data is intact | Usually recoverable |
| The RAID card has died | Stripe size, drive order and parity rotation all live on the disks | You need no identical card |
| Files came back but nothing mounts: guests, databases | Recovered and consistent are not the same thing, and only consistent counts | That is the VMware and database pages |
Every item gets its own case number on the day it lands here. An engineer traces the fault, gives you a plain assessment of what is realistically recoverable, and puts one fixed price in writing. The diagnosis is free, you are under no obligation, and chargeable work starts only when you say go.
Switch off, mark each disk with the bay it came from, and leave every prompt alone. Every member is then cloned individually on purpose-built hardware, the ones the controller condemned included, before anything is interpreted.
Inside those images sit DDF or RIS records holding the RAID level, stripe size and member order, with the parity rotation too where the array is RAID 5 or RAID 6. That is enough to rebuild the array in software, which makes a dead controller irrelevant.
Whatever layer sits above the array gets mended on the rebuilt copy — NTFS, ReFS, a VMFS datastore, ext4, XFS — and then the real test happens: virtual machines start, databases attach, shares open.
You get the full list of recovered files first, and nothing is charged until you approve it. Data goes back on fresh media, return postage paid, and the job stays open on our side until you confirm every file opens at your end.
Here is what those two options really mean: Import overwrites the live configuration with whatever the foreign metadata claims happened; Clear wipes the DDF map off every member permanently. One keystroke each, no undo on either — yet with images already taken, neither one can cost you anything. Imaging first is not caution. It is the entire plan.
The UPS gave out before the mains came back, and the Smart Array returned with prompts nobody dared answer. All four members were imaged, the RIS metadata read out and the delayed parity respected. From that rebuild the practice-management database mounted whole — good to the last write the cache had flushed before the power went.
Rarely. It is usually controller state, array metadata or a damaged file system, on disks that are physically sound. Shut it down, click through no prompts, and the odds stay firmly with you.
The PERC has read metadata on those disks that conflicts with its own record — usual enough after a board swap, reordered drives or a failing controller. It halts on purpose. Either option on that screen can wipe data; image the drives first and neither option can do harm.
Yes. The array layout rides on the disks: PERC and MegaRAID write DDF metadata to a standard, while HP uses RIS blocks. Because rebuilds run against bench images, a matching controller isn't needed.
Both — and the difference matters. Recovering a VMDK or an MDF file is one half; persuading the hypervisor or the database engine to mount and open it is the other. Our VMware and database pages deal with that second layer.
Switch a failing device on again and you lose a little more. Open a case before you do — the diagnosis is free, whatever it finds.