A LaCie external RAID unit, working normally, with every disk pulled and replaced at once — on the reasonable assumption the box would notice and rebuild itself. It did not, because the thing that would have done the noticing had just been removed.
← All case files · £300 + VAT, flat
The client wanted to change the disks in their LaCie RAID enclosure and fitted a full set of replacements. Not an unreasonable thing to attempt, and nothing in the interface warns against it.
On startup nothing worked. The unit would not initialise, would not present a volume and would not accept the new disks. Attempts to reassemble the array by hand with Linux tooling got nowhere. And when the original disks went back in, the enclosure no longer recognised those either.
Power supply, backplane, SoC, network port. What makes it a NAS — the operating system, the web interface, the array management — is software, and software has to live somewhere.
Linux-based units almost universally carve each disk into three: a small system partition of a couple of gigabytes at the start, a swap partition, and the remainder as the data member. The system and swap partitions are themselves mirrored across every disk in the unit, so losing one member does not lose the operating system.
The bootloader in flash can start, find no root filesystem on any member, and get no further. The unit is not refusing to rebuild — it has no software running with which to perform a rebuild.
Vendors publish a procedure for exactly this: boot the unit from a recovery image over the network or from USB to reinstall the system partitions onto blank disks. It is documented, and it is nowhere near the front of the manual.
This is the part that turned an inconvenience into a recovery job.
By the time the original disks went back in, the unit had been through several initialisation attempts with new disks present. Each of those wrote fresh RAID metadata — a new array UUID, new device roles, new event counters — and updated the unit’s own configuration to match.
So when the originals returned, the enclosure compared the array UUID it now believed in against the one written on those disks, found they disagreed, and classified the members as foreign. From the unit’s point of view that is correct behaviour: metadata it does not recognise is exactly what a disk from someone else’s array looks like, and assembling it blindly would be the more dangerous mistake.
The manual Linux attempts compounded it. Every mdadm --create run against a set of members writes new superblocks — it does not examine what is already there. Each attempt therefore destroyed a little more of the evidence needed to establish the original layout, which is why the point at which someone stops experimenting largely determines how much comes back.
The data itself was untouched throughout. What had changed was the description sitting on top of it.
All the original disks were imaged read-only before anything was attempted. Nothing had failed mechanically — SMART was clean across the set. This was entirely a configuration problem, which is a good position to start from and a poor one to keep experimenting in.
The array was then reassembled from the images with the enclosure removed from the equation entirely. Because the superblocks had been overwritten, the geometry could not be read out and had to be derived from the data instead: candidate combinations of chunk size, member order, parity rotation and data offset were applied to the images, and each tested against whether recognisable file system structures appeared at the offsets they should occupy.
That test is what makes the approach sound rather than speculative. A wrong geometry does not produce a slightly wrong volume; it produces noise. When the superblock, the directory records and the allocation structures all resolve coherently in the same arrangement, the arrangement is right — and it was confirmed against several widely separated regions rather than accepted on the strength of the first megabyte.
From the assembled volume the file system was rebuilt and the data extracted, verified by opening, and returned on separate media rather than back into the LaCie.
About 98%. The shortfall was structures damaged during the failed initialisation attempts — specifically the regions the enclosure had written over while trying to create a new array, which happened to overlap file system metadata rather than only the superblock areas.
The point worth making is not that the client did something foolish. Swapping disks in a storage box is a reasonable thing to expect to be able to do, and these units are sold on the promise that they manage themselves. It is that they hide how they work, and nothing tells you the operating system is on the disks you are about to remove.
If you are migrating to new disks, replace them one at a time and let each resync complete before touching the next — that way the operating system is never absent from the unit. Or copy everything off first and build the new array from scratch, which is faster and carries no risk at all.
And if a unit has already rejected your original disks: stop. Every further attempt to create or assemble an array writes metadata over what is needed to work out the original layout. NAS and RAID recovery is from £500 +VAT after a free 48-hour diagnostic.
Drop the drive at our Oxford Street reception, or post it to us — it costs nothing to find out what happened. You get a written figure from the fixed bands before any work begins.