Devices · arrays and server drives
Array and server work starts at £500 + VAT, and the look that sets the figure is free. What finishes an array is rarely the first fault — it is the response to it: a rebuild demanding one faultless end-to-end pass from a worn member, the rejected disk pushed back in, bays swapped round in hope. A mirror flatters its owner, because two disks bought together, fitted together and worked equally hard tend to wear out together. Sets reach the Reading bench from a warehouse office at Theale and an engineering shop on Worton Grange. Nothing here degrades further: every operation runs on images.
An engineer answers, and looking is free
0800 6890668
| What you are seeing | What is likely wrong | What happens next |
|---|---|---|
| Dell PERC: Foreign Configuration Found | The drives describe a set the card does not recognise | Ignore the prompt. Image every disk. |
| HP: 1786 — Drive Array Recovery Needed | Redundancy has gone, with a rebuild queued or half done | Power it down and image the whole set |
| HP: 1784 — Drive Array Drive Failure | A member of the set has failed | Fitting a fresh disk will not fix it |
| 1788 — Drive Array Reports Incorrect Drive Replacement (HP) | The disks have gone back in the wrong order | Stop. Bay order decides everything. |
| Virtual Drive Degraded, or Offline | The volume has lost parity, or has gone completely | Take the server right off |
| HP: 1720 — SMART drive detects imminent failure | A disk still in the set is warning that it will fail | Have it imaged the same day |
A case number goes on your device the day it reaches us, and an engineer then finds the real fault — free, and before anything else happens. You are told plainly what will come back and what will not, with one fixed figure in writing beside it. Nothing chargeable starts until you have read that and said yes.
Every member is copied on hardware built for imaging failing disks, the rejected ones included. After that the job lives entirely on those copies, and not a byte goes back to the disks you sent.
The members carry their own metadata, and out of it comes the running order, the size of the stripe and the rotation of parity. From there the set is assembled in software over the images, on equipment of ours. Your controller plays no part, and nothing is ever told to rebuild.
The file system comes next, repaired on the assembled copy, with the virtual-machine containers and database stores opened after it. You get the file listing to read against what you expected, and nothing leaves the building until you have.
You see the file list first, then decide. Nothing is invoiced until you have said yes, and on most jobs there is no fee at all if the data does not come back. What we pull off goes onto media bought in for your job, and the postage home is ours. The case stays open on the bench until you tell us the files open on your own machine.
Why single parity ran out of headroom: the published figure for a consumer SATA disk is one unreadable sector per 1014 bits — one bad sector for roughly every 12.5TB it hands over. A rebuild on a large single-parity set asks each surviving member for many times that, faultlessly, in a single pass, and that is where such rebuilds stop. The rate is the manufacturers' own, and how closely it matches real disks is still argued over.
A second member dropped out part-way through the rebuild on the Friday, and the live volume stopped mounting. The array was powered down and left alone. All four members were cloned to our own storage, and the stripe was reassembled from three good clones plus the fragments the fourth still returned. The Monday shift ran as normal.
Send it. Whichever member the controller dropped can still hold the newest version of some stripes, and every block is pulled from the disk that hands it over most cleanly.
No. Where each disk sat, how big the stripe is and the direction parity moves are all worked out from what is written on the drives. That is bench analysis rather than guesswork. Number them anyway if you still can, because it saves an hour.
Both. Once the set is standing again, the VMDK and VHDX containers come out along with the database stores, and each is then mounted on the bench and opened up — a filename in a listing tells you nothing about the state of what is inside it.
Reckon on four to seven working days once several disks are in play. Tell the engineer if the business has genuinely stopped trading: the queue position changes, and intake is booked around whatever date you have to meet.
You pay nothing for the look. What comes back is a list — the files that opened, the ones that did not, and one fixed figure to finish the job. Leave it switched off until you have that in writing.