Devices · arrays and server storage
The first fault rarely finishes a RAID array. What finishes it is what comes next: a rebuild demanding a full read from start to finish of a worn member until it fails, rejected disks pushed back into their bays, disks swapped around in the hope it helps. People often overestimate the value of mirroring: the two halves went into their bays on the same afternoon and have seen identical usage since. Sets come to us from an office at Plymouth's Sutton Harbour, from a boatyard on the Cattewater and from an engineering shop outside Camborne. Everything runs on images, so nothing degrades while it is here.
You will be talking to an engineer
0800 6890668
| What turns up | What that points to | Where to start |
|---|---|---|
| Foreign Configuration Found (Dell PERC) | The drives describe a set the card cannot identify | Answer none of it. Image each member. |
| 1786 — Drive Array Recovery Needed (HP) | Redundancy has gone, with a rebuild queued or partly underway | Shut it down and image the set |
| 1784 — Drive Array Drive Failure (HP) | A member of the set has died | Fitting a new disk will not resolve it |
| 1788 — Improper Drive Replacement (HP) | The drives went back in the wrong sequence | Halt. Bay order decides it. |
| Virtual Drive is Degraded / Offline | The volume has lost its parity, or has gone down entirely | Take the server fully off |
| 1720 — SMART drive detects imminent failure (HP) | A disk still in the array is warning it will fail | Get it imaged that day |
Whatever is delivered is booked in using a unique reference (case number) on the date it arrives at the bench. The engineer will identify the actual fault at no charge. This gives a straightforward answer on what can be recovered from the drive and what cannot, plus one written quotation. There will be no further activity until you have read and accepted the quotation.
Each drive goes onto purpose-built imaging equipment, including the ones the controller card had already rejected. All work runs on the copies after that point, and not a single byte goes back to what you sent us.
The layout itself tells you the order the disks ran in, how big the stripe was and how parity moved around. The set is then rebuilt over the images on our own machines, without ever using a controller card. At no time is anything told to rebuild.
Once the array is running again, we repair the file system, and then the virtual machine containers and databases follow. Before any of it goes out, everything is fully listed and checked.
Give yourself time to consider it. It costs you nothing. We list all of the files we recover for you before sending out an invoice, and we only ask for payment once you have authorised it. We also buy media specifically for your recovery and send it back to you, with the return postage paid by us. The case stays here on our bench until we have your confirmation that the files open properly on your own machine.
Where single parity got its name: makers specify one unreadable sector per 1014 bits on a consumer SATA disk, which works out at about one in every 12.5TB read. Rebuilding a large single-parity set asks a lot more than that of every disk still running, without a single stumble, and that is when rebuilds typically fail. That figure comes from the manufacturers rather than from us, and its real-world impact is still argued over.
On Friday, a second member failed during a rebuild and the live volume became unreadable. The array was shut down and stayed that way. Each of the four disks was imaged onto our own equipment, and the stripe was read back from the three good copies plus whatever was left on the failing fourth disk. The Monday shift started on time.
Include it. A drive the controller threw out will often hold the freshest copy of some stripes, and each block comes from whichever member gave it cleanest.
Not at all. Where each disk sat, how big the stripe is and the order parity moves round can all be determined from what is written on the drives themselves. This is bench analysis, not guessing.
Both. First the VMDK and VHDX containers come off, along with any database stores, and each is then mounted and opened here, because having an item listed proves nothing by itself.
Four to seven working days where several disks are involved. When trading has completely stopped, tell us by phone. The job moves up the queue and we plan the intake around the date you need.
Diagnosis costs nothing. We give you a report listing which files can be read, which cannot, and what is needed to get them off. Do not connect the drive until then.