Data Recovery Case File · NAS & Network Storage · Two Layers, Two Faults
Restoring Redundancy Does Not Repair a Filesystem
His enquiry describes a repair that succeeded without fixing anything. A five-drive unit where "the volume seems to have crashed. The drive in slot one was unreadable so I changed this drive and rebuilt the data, but the volume says it is still crashed. The 10TB of data" remains inaccessible. The rebuild did exactly what a rebuild does — and what it does is restore redundancy at the array level, which is a different thing from repairing the filesystem sitting on top of it.
| Media | Five-drive network storage unit with parity — failed member replaced and array rebuilt successfully; volume still reporting as crashed; approximately 10TB held |
| Reported situation | Five-drive network unit with a parity configuration · volume reporting as crashed · one member unreadable · member replaced by the owner · array rebuild completed · volume continuing to report as crashed · approximately 10TB of content required |
| Fault class | Filesystem damage above an array that is now healthy — rebuild restoring block-level redundancy without addressing volume structures |
| Equipment used | Array health distinguished from volume health before any conclusion · no further rebuild or volume repair permitted · all members imaged individually write-blocked · array assembled offline from images · filesystem structures rebuilt from surviving copies on the assembled volume |
The decode: what a rebuild restores, and what it never touches
What an array actually provides: a reliable supply of blocks. It takes several physical disks and presents them as one large space, with parity so that a failed member can be reconstructed. That is the entire job — the array knows about blocks and nothing about files.
What sits on top of it: a filesystem, exactly as on a single drive. It records what files exist, what they are called, and which blocks hold each one — and it is an entirely separate structure with its own integrity, which can be damaged while every block beneath it is perfectly readable.
So what his rebuild achieved: the array can now supply every block again. Redundancy is restored and the storage layer is healthy, which is exactly what he asked it to do and it worked.
Why the volume is still crashed: because the filesystem's own structures are damaged, and nothing about reconstructing parity examines or repairs them. The unit is reporting the same fault it had before, because the fault was never at the level he repaired.
Why the two get conflated constantly: the unit presents one thing to the user — a share, with files in it — and both layers have to work for that to appear. When it stops appearing, the visible remedy is the array one, because that is what the interface offers.
What the rebuild cost, and this is worth knowing: a complete read of every surviving member at sustained maximum load, for as long as ten terabytes takes. That is the most demanding operation those drives will ever perform, undertaken on a set where one member had already failed — which is real risk taken for no benefit, because the fault was elsewhere.
Why the original failure may still explain everything: a member becoming unreadable while the volume was in use can interrupt writes, and interrupted writes damage filesystem structures. So the drive failure caused both problems, and only one of them was addressed.
What must not happen now: no further rebuild, and no acceptance of any offer to repair or recreate the volume. A volume repair on a damaged filesystem discards what it cannot reconcile, and recreating one writes a fresh empty structure over the old.
On the bench
Array health was distinguished from volume health before any conclusion — an array supplying blocks with parity and knowing nothing about files, while the filesystem above it records what exists and where, as a separate structure that can be damaged while every underlying block reads correctly. No further rebuild or volume repair was permitted. All members were imaged individually write-blocked, the array assembled offline, and filesystem structures rebuilt from surviving copies on the assembled volume.
The outcome
Array health separated from volume health, no further rebuild permitted, and the filesystem rebuilt against an offline assembly. Free assessment, one fixed written figure including VAT; 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: your rebuild worked. It restored redundancy at the block level, which is all a rebuild does — and your fault is in the filesystem above it, which nothing about reconstructing parity examines or repairs.
Array that rebuilt and still will not present its volume
Don't rebuild again, and refuse any offer to repair or recreate the volume — a repair discards what it can't reconcile, and recreating writes a fresh empty structure over the old one. Your rebuild succeeded at what it does: an array supplies blocks with parity and knows nothing about files, so reconstructing a member restores redundancy at the storage layer. The filesystem sits above that as a separate structure recording what exists and where, and it can be damaged while every block beneath reads perfectly. The two get conflated because the unit presents one thing and both layers must work. Your original member failure likely caused both.
Don't rebuild again — call Oxford Data Recovery on 01865 593000; array health distinguished from volume health, members imaged individually, filesystem rebuilt against an offline assembly.
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.