A 24-drive SuperServer holding databases, virtual machines and the operational core of a business. During routine maintenance the drives were pulled and put back in a different order, and nobody had written down the original sequence. Not one disk was faulty.
A junior engineer pulled the drives during a maintenance window and reinserted them without recording which bay each had come from. On restart the controller could not assemble the array, and everything the business ran on became unreachable.
The internal IT team tried to rebuild the configuration and could not. That is not a criticism of them — as the next section explains, it is not a problem anyone solves by trying arrangements.
The instinct is to shuffle the drives until something works. It is worth seeing the number.
Twenty-four members can be ordered in 24 factorial ways: 620,448,401,733,239,439,360,000 arrangements. Roughly 620 billion trillion. Testing one per second, you would still be going long after the sun had burned out, and each test on live hardware takes rather longer than a second.
Worse, the attempts are not free. Every assembly attempt risks the controller writing fresh metadata to the members — a new configuration signature, updated sequence numbers, a reinitialised descriptor — and enough of those will destroy the very evidence needed to establish the original order properly.
This is one of the cases where doing nothing is genuinely the best available action.
You do not guess. The disks record enough between them to reconstruct the sequence, and it is read out rather than searched for. Four independent methods, cross-checked against each other.
Controller metadata. Most controllers write a descriptor onto each member recording its role and position. Where it survives, it is the fastest route — but it is treated as a hint rather than a fact, because the controller had already failed to assemble the array and its account of itself is therefore suspect.
Stripe continuity. Data is written across members in a repeating pattern, so a file larger than the stripe size necessarily continues from one member onto the next. Find a structure that runs across the set — a large contiguous file, a database extent, a virtual disk — and observe where each portion continues, and you have established which disk follows which, directly from content.
File-system landmarks. Large file systems place their structures at predictable intervals across a volume rather than clustering them at the front. Locating those in the images and seeing which member holds which one pins disks to positions independently of anything the controller claimed.
Parity arithmetic. This is the decisive test. On a parity array the parity block for each stripe is computed from the data blocks in that stripe. So a candidate ordering can be checked rather than believed: assemble it, recompute parity across a sample of stripes spread across the volume, and compare against what is stored. The correct order resolves everywhere. A wrong order fails immediately and unambiguously — there is no partial credit.
That last point is what makes this work sound rather than speculative. The answer is not the arrangement that looks plausible; it is the only arrangement that satisfies the arithmetic.
All 24 drives were imaged read-only first, which on that number of members is several days of work before any analysis could begin. Everything afterwards ran against the images, so no attempt could disturb the originals — and on a job with a search element that matters more than usual, because being able to try an arrangement and discard it costs nothing on a copy.
The order was established from the evidence above, cross-checked between methods, and the array assembled virtually. The file system was rebuilt from the assembled volume, and the databases and virtual machine files checked for structural consistency rather than merely extracted — a virtual disk that copies cleanly can still refuse to boot if it was captured mid-write.
Everything. There had never been a hardware fault, so once the order was right the data was simply there.
Twelve days, almost all of it imaging 24 drives rather than solving the puzzle. That is worth knowing if you are ever in this position: the clock is set by the number of members, not by the difficulty of the analysis, and a large array takes a long time to secure before anyone can start thinking.
A strip of tape and a marker pen would have prevented the entire thing. Before removing drives from any array, number them by bay — and photograph the front of the chassis first, which takes five seconds and records the order for you whether or not you remember to label anything. If it has already happened, do not shuffle the disks looking for the right arrangement: there are more orderings than you can test, and every attempt risks the controller overwriting what would have told us the answer. Server and RAID recovery is from £500 +VAT after a free 48-hour diagnostic.
Send the device over with a short account of what happened to it. The diagnostic costs nothing and commits you to nothing, and the figure that follows is fixed in writing before anything is opened.
Nothing can begin until the device is on the bench, which makes this the only step that needs anything from you. Pack it properly, put your details in with it, and send it over. What follows is a free diagnostic and a written figure, in that order.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Tell us what the device is, what it is doing, and anything already tried — an engineer will come back with a realistic view of the odds and a price band, before you commit to posting anything.
We’ll be in touch shortly. For anything urgent, call 0161 871 0788.
Almost always, yes. The order is recorded in the data itself — controller descriptors, stripe continuity, file system landmarks and parity arithmetic all point to it. It is read out rather than guessed at, and no disk needs to have failed.
No, for two reasons. With 24 drives there are around 620 billion trillion possible orders, so testing is not feasible. And each attempt risks the controller writing new metadata over the evidence needed to determine the real order.
Four independent methods, cross-checked: metadata the controller wrote to each member, data structures that continue from one disk into the next, file system landmarks at predictable positions, and on a parity array, whether the arithmetic resolves. Wrong orders fail immediately.
Because imaging 24 drives takes several days before any analysis begins, and everything runs against the images rather than the originals. The timescale is set by the number of members, not by the difficulty of the reconstruction.
Number the drives by bay before removing them, and photograph the front of the chassis first — five seconds, and it records the order permanently. Most arrays that reach us with lost sequencing were dismantled in a hurry.
Yes, and they are checked rather than just extracted. A VMDK or a database file can copy cleanly and still refuse to start if it was captured mid-write, so structural consistency is verified before it goes back.
Start with an instant online quote, or call and talk it through with us first. You'll have a clear, fixed price before any work begins.