Job sheet · NAS & RAID · BHD-2025-8341
A Four-Bay Synology, One Failure Too Many.
A Jewellery Quarter workshop kept its four-bay Synology behind the polishing bench, where the fan drew in fine dust year after year. A bad-sector warning on one bay had been running since Christmas, its alerts switched off rather than acted on. An order file would not open, somebody power-cycled the box, and back it came saying volume crashed
. The note taped to the lid said clone the bad disk in and let it rebuild
. We would not.
Sounds like yours? Give us a ring.
0800 6890668
What that means.
Two members down is one past what RAID 5 will bear. Parity gives a set a single disk's worth of cover, spread a little into every stripe, so one absence can be calculated back and a second cannot, because nothing is left to solve with. Powering the box up to watch what it did would have put two tired survivors under load, and handed a crashed volume the chance to write fresh metadata over the exact structures a reconstruction has to read. It stayed off. The clone-and-rebuild instruction was refused in writing, since feeding a dying disk into a live array only leans harder on the members that still work. Nothing was allowed to run. Every disk was copied first, and every decision after that was taken on the copies.
What did the work here.
The order of the work →| Equipment | The job it did | What it adds |
|---|---|---|
| DeepSpar Disk Imager 4 | New head stacks into each dead member, the more recent casualty copied first | Head mapping first, then one surface at a time, with resets, timeouts and power all governed |
| Atola TaskForce 2 | Took the two good disks together while the failed pair were on the bench | Every disk in the array goes through the imager together, not one after another |
| UFS Explorer RAID Recovery | Pulled the mdadm superblocks and put the volume back together from the images | Reads the volume layers a NAS puts over its array, not only the RAID underneath |
What we did.
Treat the two survivors as casualties as well
A disk that has spent months propping up a degraded array rarely comes through clean, and both survivors had collected a scatter of pending sectors. They went onto the TaskForce together and were copied while the failed pair sat on the bench. Two streams at once cut days off the job and left nothing in the set merely assumed to be sound.
What the logs said about when the first disk left
A matched head stack went into each casualty and both read again. The logs then changed the shape of the case. The bay grumbling away since Christmas had, it emerged, dropped out of the set in January, putting its contents nine months adrift — the volume in an earlier state, not the state the crash left behind. The newer failure held the version that mattered, and its damage was confined to bands we could work around.
Assemble from three images and leave the January one out
Stripe size, member order and which way parity rotates were taken off the array's own metadata, not guessed at. The reconstruction used the three current images and ignored the January dropout, because blending blocks written months apart is how convincing corruption gets manufactured. What the newer casualty never surrendered turned out to sit in space the filesystem had never allocated.
How it closed.
The volume came up first time. Every CAD file, casting record and job book was checked off against the workshop's own order numbers before the new disks were posted out. The Synology now sits in the office, out of the dust, with the warning emails switched back on.
Other pages worth a look here.
The RAID & NAS cases.
Is yours behaving the same way?
Switch the device off, post it in, and decide nothing until the diagnosis comes back to tell you where you stand.