Devices · Servers & RAID sets
The first dead member rarely ends an array — what comes after it does: a rebuild that pushes an already-tired disk over the edge, someone gambling on forcing the set online, a healthy drive pulled from the wrong bay. Everything we do runs on images, so nothing gets worse once it reaches our bench.
Speak to an engineer about it
0800 6890668
| The wording | What that tells you | First step |
|---|---|---|
| Foreign Configuration Found (Dell PERC) | Metadata on the disks disagrees with what the card has stored | Not Import, not Clear — image |
| 1786 — Drive Array Recovery Needed (HP) | Redundancy has gone: a rebuild is outstanding or stopped part-way | Power off, then image |
| 1784 — Drive Array Drive Failure (HP) | One of the disks has died | No hopeful hot-swapping |
| 1787 — Drives Improperly Attached (HP) | Members sitting in the wrong bays | Sequence counts — halt |
| Virtual Drive is Degraded / Offline | Either no parity protection left, or the volume is down | Shut the array off |
| 1720 — SMART drive detects imminent failure (HP) | A live disk is warning it is on its way out | Arrange imaging now |
As soon as it lands with us, your device gets its own case number. An engineer works out the fault, says what can genuinely be pulled off, then puts one fixed price in writing — no charge for diagnosis, no obligation, and no chargeable work until you approve it.
Each disk, including any the controller threw out, goes onto dedicated imaging hardware. From then on we touch only copies; your originals are never written to.
Member sequence, stripe size and the direction parity rotates are all derived from the data on the disks. The set is then assembled across the images on our own machines: no card involved, and no rebuild ever started.
The file system, virtual machine containers and database stores are put right on that reconstruction, and checked against a listing before anything is released.
You sign off a complete list of the recovered files first; only then does the recovery fee fall due. Everything returns on fresh media, postage paid, and the job stays open until you confirm the files open at your end.
Where the RAID 5 warnings actually come from: a consumer SATA disk is specified at something like one unreadable sector per 1014 bits — roughly one for every 12.5TB pulled off it. Restore a large single-parity array and the survivors are asked to deliver more than that in one pass, which is how a rebuild kills itself. The number is published, not folklore, though what it really means for RAID 5 is still argued over.
A Friday rebuild that swallowed a second drive left production data stranded on the server. We imaged all four disks, rebuilt the stripe from three-and-a-bit usable images, and the factory was running again by Monday.
Yes — send the whole set. A drive marked 'failed' can still carry the most current version of certain regions, and the rebuild picks the best source for every block from across the group.
No — disk order, block size and parity rotation can all be read back from the patterns in the data on the disks. That's standard analysis, not guessing.
Yes. With the array reassembled, VMDK, VHDX and database stores are treated as primary targets — and we check each one mounts, rather than merely being present.
Expect four to seven working days on a multi-drive job; where a business is genuinely down, work can run continuously — tell us on the phone and we'll build the intake around that.
Powering a damaged device up again costs you data. Start a case first; diagnosis is free whatever you decide.