Devices · arrays, NAS and servers
Take the server off power before anything else. The first fault rarely ends an array; what ends it is the response to that fault — a rebuild that demands one flawless pass, end to end, from a member already worn; a rejected disk returned to the bay it came out of; drives shuffled between bays in hope. Mirrors flatter their owners too, because two disks out of one carton, fitted the same afternoon and worked at the same rate ever since, run out of hours at much the same point. The kind of London address these arrive from: a Harley Street practice with its imaging on a single NAS in a basement, or a Mayfair firm of under fifty people and nowhere to put a server room. Array and server work opens at £500 + VAT, the diagnosis that sets the figure is free, and nothing degrades any further here, because every step happens on images.
Put it to an engineer — the first look costs nothing
0203 0868633
| What is going on | The usual reason for it | Where that leaves you |
|---|---|---|
| A Dell PERC reporting Foreign Configuration Found | The drives describe a set the controller cannot place | Answer nothing. Image every member first. |
| 1786 on an HP console: Drive Array Recovery Needed | Parity cover has gone, with a rebuild queued or half-run | Off power first, then image the whole set |
| On an HP: 1784, Drive Array Drive Failure | One member of the set has failed | A replacement disk will not mend it |
| On an HP: 1788, Drive Array Reports Incorrect Drive Replacement | Somebody has refitted the disks out of sequence | Stop now. Bay order decides everything. |
| Virtual Drive: Degraded — or Offline | Parity has gone, or the volume with it | Take the server off power completely |
| On an HP: 1720, SMART drive detects imminent failure | A drive still in service has flagged imminent failure | Image that disk the same day |
A case number goes on it the day the parcel lands, and an engineer settles what has truly failed before anything else happens — free of charge, and first in the order of work. Back to you come two things together: a straight note of what is liftable and what is not, plus one figure, fixed and written down. Accept it, or decline and owe us nothing.
Each member, rejected ones included, is copied by hardware built for failing disks. Every later step happens on those copies. Nothing is ever written back to a drive you sent.
Three facts come off the members' metadata: which disk sat where, the stripe size, and which way parity rotates. The set is then assembled in software on our own equipment, over the images. Your controller plays no part in it, and no disk is ever asked to rebuild.
Next the file system is repaired, on the assembled copy rather than on anything of yours, and then the VM containers and the database stores are opened one by one. You check that listing against what you expected to see; nothing ships before you have.
What was recovered is listed for you first, and only then does a bill exist. Approve the list and it is invoiced; turn it down and it is not — and where nothing has come back, most jobs carry no charge whatever. Recovered data travels home on fresh media bought in for your job, with the postage at our end. Your case is not closed until you have read those files on a machine of your own.
Why single parity ran out of headroom: a consumer SATA disk is specified at one unreadable sector in 1014 bits, which comes to about one bad sector in each 12.5TB read back. Rebuilding a large set that carries only one parity disk demands several times that much clean reading from every remaining member, in one uninterrupted pass, and that is where the rebuild stops. The number is the makers' own, and how far real disks match it is still a matter of argument.
The rebuild was halfway through on the Friday when a second member went offline, and the live volume would not mount at all. Power down, hands off. All four disks were copied onto storage of ours; three of those copies read sound, and the stripe went back together from them plus whatever the fourth would still yield. Monday's shift opened as it always does.
Yes, send it. The member the card threw out can still hold the freshest version of certain stripes, so it travels with the others, and each block is afterwards read from whichever disk surrenders it most cleanly.
Not badly at all. Running order, stripe width and which way parity rotates are all recorded on the drives, so recovering them is a matter of analysis rather than guesswork. Number the disks anyway where you can — the hour it saves is a real hour.
Both. With the set standing again, VMDK and VHDX containers come out alongside the database stores, and each one is mounted here and opened in turn — because a name in a file listing tells you nothing about the condition of what sits within it.
With several disks in play, reckon on four to seven working days. Say so if trading has genuinely halted: your place in the queue changes, and intake is arranged around the date you have to meet.
Looking at it is free. Back comes a list of what opened and what did not, together with a single price to finish, set down in writing while you are still free to say no. On most jobs an invoice only follows the data. Until that list reaches you, leave the drive switched off.