NAS & RAID · bench notes · HUL-2025-0341
Two Bays Down, and Nine Months Between.
A castings workshop in Goole had its four-bay Synology on a shelf next to the fettling bench, with the fan drawing grit through it for years. Bay 2 had been reporting bad sectors since Christmas; the warning emails were turned off instead of acted on. An order file then refused to open, so someone pulled the power and restarted the unit, and it came back showing volume crashed
. Taped to the lid was a note: fit a new disk and let it rebuild itself
. We did the opposite.
Sounds like yours? Ring us.
0800 6890668
What causes it.
RAID 5 holds one disk in hand. That is the whole allowance. Parity sits thinly across every stripe, so a single absent member can be worked back out; ask the same sums to account for two and there is nothing to work from. Switching the box on to see where it stood would have cost them dearly — two tired survivors made to work, and a crashed volume left able to write new metadata straight over the structures a rebuild would need. So it stayed off. The note on the lid was declined in writing: putting a failing member back into a running set only loads the disks that are still working. Nothing was switched on. The disks were copied first, and every later step happened on the copies.
The tools this one needed.
The steps we follow →| The gear | What this one did | Why we have it |
|---|---|---|
| DeepSpar Disk Imager 4 | Both dead members took new head stacks and were read, the recent one first | Grades each head first, reads one surface at a time, and keeps resets, timeouts and power under control |
| Atola TaskForce 2 | Imaged the two healthy disks side by side while the dead pair waited | Takes every disk in the set together, instead of one imager working down the row |
| UFS Explorer RAID Recovery | Took the mdadm superblocks off and reassembled the volume across the images | Puts the array back together, then unwinds the volume layers a NAS lays over it |
The stages.
The surviving disks are casualties too
Carrying a degraded array for months tells on a disk, and both survivors had pending sectors of their own by then. The TaskForce took both at the same time, and they were imaged while the dead pair waited. Running the pair concurrently saved days, and it meant nothing in the set was passed as sound without being read.
The logs gave a date to the first failure
Both casualties accepted a matched head stack and began reading. What the logs held changed the job entirely: the noisy bay had actually dropped out in January, which put its contents nine months behind — an older copy of the volume, from well before the crash. The state that mattered was on the disk that had failed most recently, and its damage fell in bands that could be worked around.
Assemble three images and leave the January disk out
Stripe size, member order and the direction parity rotates all came off the array's own metadata rather than from a guess. The assembly ran on the three up-to-date images and January's disk played no part in it: mix blocks written months apart and you build corruption tidy enough to pass a consistency check. Whatever the recent disk would not give back sat in unallocated space.
How it finished.
The volume mounted first time. Drawings, casting records and job books were checked against the shop's own order numbers before new disks went in the post. The Synology sits in the office now, away from the grit, and the warning emails are back on.
What people read after this.
Other RAID & NAS cases.
Is yours doing the same?
Turn it off. Send it to us. The diagnosis comes first. It says which files are still readable and which are not.