Devices · arrays and server drives
Array and server work begins at £500 + VAT, and the look that determines the cost is free. It is rarely the initial fault that ends an array; it is the reaction to it: a rebuild requiring one error-free end-to-end pass from a worn member, the rejected disk put back into service, bays switched round in hope. A mirror flatters its owner, since two disks purchased together, installed together and worked equally hard are likely to wear out together. Sets reach the Oxford intake lab from a warehouse office at Theale and an engineering shop on Worton Grange. From this point nothing deteriorates further: all operations run 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 an array that the card does not recognise | Ignore the prompt. Image every disk. |
| HP: 1786 — Drive Array Recovery Needed | There is no redundancy left, and a rebuild has been queued or was part-way through | Shut down the server and create a full image of every disk in the set |
| HP: 1784 — Drive Array Drive Failure | A member of the set has failed | Replacing a disk with a new one will not resolve this |
| 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 has identified that it may be going soon | Have it imaged the same day |
A case number is assigned to your device when we receive it. An engineer then finds the real fault (free) before anything else occurs; you will be advised clearly of what will be returned and what will not, along with a single written price. Charges cannot begin until you have read this and accepted.
Each member, including the rejected disks, is copied on hardware capable of imaging failing disks. Once this is done, the job resides entirely on these copies, and not one single byte returns to your original disks.
The members carry their own metadata, from which comes the running order, the stripe size and the parity rotation. Our software then assembles the set over the images, on our own equipment. Your controller doesn't come into play, and nothing is ever told to rebuild.
The file system repair is then performed on the assembled copy. Once completed, the virtual-machine containers and database stores are opened. You then check the file listing against your expectations, and nothing leaves the building until you have.
You look at the file list first and make a decision about what to do. We will never invoice anything until you have said yes, and in most cases you only pay if we recover your data. All of the information that we recover will be put on new media purchased by us specifically for this job, and our company pays the cost of postage back to you. 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: for a consumer SATA disk, the manufacturer's figure is one unreadable sector per 1014 bits, or about one bad sector per 12.5TB of data the drive hands over. A rebuild on a large single-parity set asks each surviving member for many times that, fault-free, in a single pass, and it is at this point that such rebuilds fail. The figures are the manufacturers' own, and how closely they match real disks is still argued over.
A second member dropped out halfway through the rebuild on the Friday, and the live volume stopped mounting. The array was powered off and left alone. All four members were cloned to our own storage, and the stripe was put back together with good data from three clones plus the pieces the fourth would still give. The Monday shift ran as normal.
Send it. Even though the controller dropped it, that member may still hold the newest version of some stripes, and every block is pulled from whichever drive hands it over most cleanly.
No. The position of each drive, the stripe size and the direction of parity are worked out by reading data off the disks. This is bench analysis, not a wild guess. If you still can, label each one with its original bay anyway; it could save an hour.
Both. Once the set is back together, the VMDK and VHDX containers come out along with the database stores, and each one is mounted on the bench and opened, because 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 involved. If the business has genuinely stopped trading, tell the engineer: we can move you forward in the queue, and intake is booked around the date you have to meet.
There is no charge for the look. You then receive a list of the files that opened, those that did not, and a fixed amount to complete the job. Keep it switched off until you have received that in writing.