Data Recovery Case File · NAS & Network Storage · Order Matters More Than Count

A Member That Dropped Earlier Holds Data That Is Out of Date

This enquiry concerns a server array in a working environment. A parity set of four enterprise drives on a hardware controller, where "we have suffered a failure of the array container." A parity array survives one member failing and not two — and where more than one has dropped, the sequence in which they went determines which of them can be used and which must be excluded.

The decode: why the sequence decides everything

What a parity array tolerates: one member failing. The remaining drives hold enough information to reconstruct what the missing one held, which is the entire purpose of the arrangement and it works.

What happens when a second member drops: the array goes offline. Parity can rebuild one absent member and not two, so the controller stops rather than serving data it cannot verify.

Why the order of those two failures matters so much: when the first member dropped, the array carried on without it. Every write after that moment went to the remaining drives and not to the failed one — so that drive holds a snapshot from the instant it left, and everything since is missing from it.

What follows for assembly: the stale member cannot simply be put back. Including it in a reconstruction mixes old data with current data, producing a volume that assembles cleanly and contains a mixture of two points in time — which is worse than a volume that will not assemble, because it looks correct.

So the critical question is which drive left first, and the answer is usually recorded. Hardware controllers log member events with timestamps, and that log identifies the sequence without any guesswork.

What the correct assembly then is: the members that were present at the moment the array went offline, with the stale one excluded and its contribution reconstructed from parity where possible. That returns a consistent volume from a single point in time.

Why the interface generation matters practically: enterprise drives use a different connection from consumer ones, requiring appropriate adapters and supply. They also frequently carry different sector formatting, which affects how images are handled.

What must not happen, and it is what the controller will offer: no forced online, no rebuild, and no acceptance of any prompt to restore the array. Forcing an array online with a stale member is exactly how the mixed-time volume gets created, and a rebuild writes across a member using parity that may itself be inconsistent.

On the bench

The controller event log was read for member failure sequence before any assembly — a parity array continuing without a failed member so that all subsequent writes bypass it, leaving that drive holding data from the instant it dropped. Including a stale member in a reconstruction produces a volume mixing two points in time, which assembles cleanly and is wrong. Members were imaged individually write-blocked, the stale member identified and excluded, and parity verified during offline assembly.

The outcome

The failure sequence established from the controller log, members imaged individually, and the stale member excluded from an offline assembly with parity verified. Free assessment, one fixed written figure including VAT per drive; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: order matters more than count. A member that dropped first stopped receiving writes at that moment, so putting it back mixes two points in time into a volume that looks correct and is not.

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.