Devices · arrays and servers
Power the server down before anything else. An array is rarely finished off by its first fault; what finishes it is the response — a rebuild asking a worn member for one faultless pass end to end, a disk the card rejected pushed back into its bay, drives shuffled about in hope. Mirrors flatter their owners too: a pair bought on the same day, fitted on the same afternoon and worked equally hard since will wear out on much the same schedule. Sets come to us from a 3PL office on Markham Vale and an accountancy practice in West Bridgford, Nottingham. Work on an array or a server begins at £500 + VAT, the look that sets that figure costs nothing, and here nothing degrades any further, because every operation runs on images.
Ask an engineer, and the first look is free
0115 8220606
| What is happening | What usually causes it | What that means for you |
|---|---|---|
| Foreign Configuration Found — on a Dell PERC | The drives describe a set the controller does not know | Answer nothing at all. Every member gets imaged. |
| 1786 on an HP: Drive Array Recovery Needed | Redundancy is gone, and a rebuild is queued or half-finished | Take it off power, then image the entire set |
| 1784 on an HP: Drive Array Drive Failure | One member of the set has stopped | Putting a new disk in will not mend it |
| 1787 on an HP: Drive Array Operating in Interim Recovery Mode | A member has failed and the set is running degraded | Stop there. Every member gets imaged before anything is replaced. |
| 1788 on an HP: Drive Array Reports Incorrect Drive Replacement | Somebody has put the disks back out of order | Stop there. Bay order settles everything. |
| Virtual Drive: Degraded, or Offline | Parity has gone, or the whole volume has | Get the server off power altogether |
| 1720 on an HP: SMART drive detects imminent failure | A disk still in the set is announcing its own failure | Get it imaged that same day |
Your device picks up a case number the day it arrives, and an engineer then establishes what has genuinely gone wrong — at no cost, and ahead of everything else. Two things come back to you together: a plain account of what can be lifted and what cannot, and one fixed figure in writing. Agree to that figure, or turn it down and pay nothing.
Hardware built to image failing disks copies each member, the rejected ones as well. From then on the job lives on those copies alone. Your original drives are read, and never written to.
Metadata on the members yields three things: which disk ran where, how big the stripe was, and the direction parity turns. On our own equipment, over the images, the set is then put together in software. Your controller has no part in any of it, and no disk is ever told to rebuild.
Next comes the file system, repaired on the assembled copy, and after that the virtual-machine containers and database stores are opened up. You read the file listing against what you were expecting to see, and until you have, nothing ships.
The file list reaches you before any invoice does. Say yes and it is billed; say no and it is not — and on most jobs, if nothing comes back there is nothing to pay. Whatever comes off goes home on media bought in for your case, carriage at our end. Nothing here is closed until you have opened those files on your own machine.
Why single parity ran out of headroom: manufacturers publish one unreadable sector per 1014 bits for a consumer SATA disk, which is about one bad sector in every 12.5TB read back. A rebuild across a large single-parity set demands many times that from each surviving member, in one faultless pass, and that is the point at which such rebuilds give up. It is the makers' own figure, and how well it holds for real disks is argued about still.
Friday's rebuild was half done when a second member dropped out, and the live volume would no longer mount. Power off, hands off. All four disks were then cloned onto our own storage, three of the clones came back sound, and the stripe was reassembled from those plus whatever the fourth would still give up. Monday's shift ran to its usual pattern.
Yes. Whichever member got thrown out may hold the newest copy of some stripes, so it travels with the rest; every block is then read from the disk that gives it up most cleanly.
Not really. Where each disk sat, the size of the stripe and the direction parity turns are all recorded on the drives, and getting that off them is analysis, not guesswork. Number them anyway if you can — an hour saved is an hour saved.
Both come back. Once the set stands again, VMDK and VHDX containers are extracted alongside the database stores, then mounted here and opened one by one, because a filename in a listing says nothing about the state of what it holds.
Where several disks are involved, four to seven working days is the usual span. If trading has genuinely stopped, say so — your position in the queue changes, and intake is booked around the date you must meet.
The look costs nothing. What comes back to you is a file list — what opened, what did not — plus one figure to finish the job, in writing, before anything chargeable begins. Most jobs carry no fee at all unless the data comes back. Leave the drive switched off until you have that list.