Data Recovery Case File · NAS & Network Storage · Striping Is Not Storage
The Only Copy Was on the Arrangement With No Margin
This enquiry came from a research group and the timeline is the painful part. A machine with two 2TB solid-state drives striped into a single 4TB volume: "it is refusing to boot. Just before the problem developed, we captured around 2TB of scientific data onto this machine; it was shut down and taken to a different location to connect to the network and back the data up, and then refused to boot. Our IT department have run tests and think the controller on the motherboard" has failed. If they are right, this is very recoverable — and the arrangement it was captured onto deserves saying plainly.
| Media | Two 2TB solid-state drives in a striped configuration presenting a single 4TB volume — machine failing to boot; on-board array controller suspected failed; approximately 2TB of unbacked research data held |
| Reported situation | Two drives striped into a single volume with no redundancy · approximately 2TB of research data captured · machine shut down and relocated before backup · machine failing to boot on arrival · internal testing indicating an on-board controller failure · both drives retained |
| Fault class | Array controller failure with member drives intact — stripe reassembly offline; no redundancy present by design |
| Equipment used | No controller replacement or array re-initialisation attempted · both members removed and labelled by port · each imaged individually write-blocked · stripe order, block size and offset determined from the images · volume assembled offline and validated by opening |
The decode: why a controller failure is the good outcome, and what striping means
What a striped pair actually is: two drives with data split across both in alternating blocks, presented as one volume. It exists for speed — reads and writes are served by two devices at once — and it provides no redundancy whatever. Worse than none, in fact: with data spread across both, either drive failing loses the entire volume, so a striped pair is roughly twice as likely to fail as a single drive. It is a performance arrangement, and it is exactly the wrong place for the only copy of anything.
Why that is worth saying without lecturing: striping is the sensible choice for a capture machine, where sustained write speed determines whether an instrument's output can be recorded at all. The mistake was not the array — it was that the array held the only copy for the duration of a journey. The plan was to back it up on arrival; the gap was the transit, and that is where it failed.
Why the controller failing is genuinely good news: a failed array controller does nothing to the drives. The data is intact on both members, distributed exactly as it was written — and a stripe can be reassembled entirely offline, without the original controller, provided three parameters are determined: which drive came first, how large each block is, and where the data begins. Those can be worked out from the drives themselves, so the volume can be rebuilt as a file and the data extracted from it.
Why the drives being solid-state helps: no mechanical risk, no degradation from being carried, and nothing that a journey could have damaged. If the controller is the fault, the members are in the condition they were written in.
What must not happen, and this is the real risk: replacing the motherboard or the controller and reconnecting the drives. A new controller may not recognise the existing array and will offer to create one — which writes new array metadata across both members and can destroy the layout information needed to reassemble it. Nothing should attempt to initialise, create or repair an array with those drives connected.
Why labelling matters: stripe order is one of the three parameters, and while it can be determined analytically, knowing which drive was on which port removes an unknown.
On the bench
No controller replacement or array re-initialisation was attempted — a replacement controller may not recognise an existing array and will offer to create one, writing new metadata across both members and destroying the layout information reassembly depends on. Both members were removed and labelled by port, then imaged individually write-blocked. Stripe order, block size and offset were determined from the images rather than from the failed hardware, and the volume assembled offline and validated by opening.
The outcome
Both members imaged individually, the stripe parameters determined from the images and the volume assembled offline. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode, for anyone whose striped array has lost its controller: that is the good outcome. A failed controller does nothing to the drives, and a stripe reassembles offline once order, block size and offset are established from the members themselves. Never let a replacement controller create an array with those drives attached.
Striped array whose controller has failed
Don't fit a replacement controller with those drives connected — a new one may not recognise the existing array and will offer to create one, which writes fresh metadata across both members and destroys the layout needed to reassemble them. Label which drive was on which port and leave them alone. The position is otherwise good: a failed controller does nothing to the drives themselves, and a stripe can be rebuilt entirely offline once three things are established from the members — which drive came first, how big each block is, and where the data starts. Worth knowing for next time that striping gives you speed and no redundancy at all, and roughly doubles your failure rate, so it's the wrong place for anything to sit unbacked.
Don't let anything create a new array — call Guildford Data Recovery on 01483 901310; both members imaged individually, stripe parameters determined from the images, volume assembled offline and validated.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.