Servers · RAID array recovery
In most servers that reach us the disks are still turning. What has gone is the machinery around them: a controller whose record no longer matches the drives, a boot prompt where both keys do damage, a cache still holding writes when the mains dropped. Every stage runs on images, your card is not needed, and what comes back is the volume itself — shares, databases, guest machines. Birmingham law firms and Black Country machine shops post the same box of drives.
Tell an engineer what it is doing
0800 6890668
| What you see | What is behind it | What to do |
|---|---|---|
| PERC screen: Foreign Configuration Detected | The layout held on the drives disagrees with the one in the card, so the boot stops on purpose — nothing has gone yet | Leave the prompt alone |
| 1786 — Drive Array Recovery Needed (HP) | A rebuild is running, or stalled part-way through | Shut it down and image it first |
| Amber bay lights after the mains dropped | Writes stopped mid-flight and a cache nobody can account for, though the layout itself is still on the members | Do not force it online |
| The server starts and the data volume is gone | The fault is in the card's state or the file system; under both of them the data is fine | Usually recoverable |
| The RAID controller is dead | Member order, stripe width and parity direction all live on the disks | No identical card required |
| Files copied out, but no guest or database will start | Copied is not the same as consistent, and only consistent data is any use | See our database recovery page |
Every item gets a case number of its own the day it lands. An engineer then works out what has actually failed and tells you plainly which files have a real chance of coming back and which do not. Only then does a price follow: one figure, fixed, in writing, and it costs you nothing to see it. Nothing is charged until you say yes.
Shut the server off. As each drive leaves its bay, mark it with that bay number. Ignore whatever the console is asking. In the lab every disk is copied on its own, on hardware made for imaging, and that includes the ones the card had thrown out. Only then is any of it read as files.
Inside those images sit the DDF or RIS records. They give the RAID level, how wide the stripe runs, which member sat in which slot and, on RAID 5 and 6, which way the parity turns. Once that is settled the set goes back together in software, and a burnt-out card stops mattering.
Whatever file system was sitting on top — NTFS, ReFS, a VMFS datastore, XFS, ext4 — is repaired on the rebuilt copy, never on your drives. Then the part that decides the job: guests power up, databases attach, shares mount and the files inside them open.
No invoice is raised until the full list of recovered files has sat in front of you and you have said go ahead. Your data comes back on media we buy new, posted at our expense, and the job is not closed here until every file has opened on your own machine.
What that prompt is really offering: Import writes whatever the foreign metadata claims over the card's live configuration; Clear wipes that map off every member for good. One keystroke picks either, and this screen has no undo — though once full images exist, neither choice can take a thing from you. Imaging is not a precaution taken first. It is how the job is done.
When the mains came back the Smart Array offered choices nobody in the practice could safely take, the battery having emptied while the power was off. Each member went to an image first. Only then did the RIS metadata come off, with the delayed parity allowed for, and the rebuild ran on copies alone. The practice-management database opened complete, current to the final write the cache had committed.
Usually not. In most cases the platters are intact and the trouble sits above them — in the card's own record, in the array map, or in a file system that has taken a knock. Leave it switched off, answer nothing on screen, and the odds stay with you.
It means the card has found a layout on the drives that does not match the one it is holding. Swap a board, put a disk back in the wrong slot, or run a controller that is on its way out, and up it comes. Stopping there is the safety feature. Import and Clear can each cost you data. Image first and neither can.
No. The geometry travels on the disks: DDF, a published standard, on PERC and MegaRAID, and HP's own RIS blocks. The set is put back together in software against bench images, so no identical card ever has to be found.
Both, though they are two pieces of work rather than one. Lifting a VMDK or an MDF off the rebuilt volume is the first. Getting a hypervisor to mount it, or SQL Server to attach it, is the second, and our database recovery page deals with that stage.
Every extra power-up takes something off a drive that is already going. Leave it switched off and let the free diagnosis say what still reads.