NAS & RAID · job sheet · CDF-2025-0341
Two Bays Gone, Nine Months Between Them.
A castings workshop in Splott kept its four-bay Synology on a shelf beside the fettling bench, where the fan pulled grit through it year after year. Bay 2 had flagged bad sectors since Christmas, and the alert emails were switched off rather than answered. Then an order file refused to open, somebody cut the power and brought the box back up, and it returned with volume crashed
on the screen. A note taped to the lid read put a new disk in and let it rebuild
. That is not what we did.
Does that match yours? Call us.
0800 6890668
Why that happens.
RAID 5 keeps one disk in reserve and no more. Parity is spread thinly through every stripe, so one missing member can be calculated back; ask the same arithmetic to cover two and there is nothing left to work from. Powering the box up to find out what state it was in would have been the expensive move: two tired survivors put under load, and a crashed volume free to scribble new metadata across the structures any reconstruction depends on. It stayed off. We declined the clone-and-rebuild note in writing, because feeding a failing member back into a live set only puts weight on the disks still working. Nothing ran. The disks were copied first, and everything that followed was done to the copies.
What we used on this one.
Every step, in order →| The tools | What it did here | Why it helps |
|---|---|---|
| DeepSpar Disk Imager 4 | Read both dead members after new head stacks went in, the newer one first | Maps the heads first, works surface by surface, and keeps resets, timeouts and power in hand |
| Atola TaskForce 2 | Copied both survivors in parallel while the dead pair waited their turn | Images every member of the set at once, instead of working through them one by one |
| UFS Explorer RAID Recovery | Lifted the mdadm superblocks and reassembled the volume from the images | Not just the RAID: it also unpicks the volume layers a NAS stacks on top |
How it went.
The two working disks count as casualties
Months of propping up a degraded array leaves a mark, and both survivors had picked up pending sectors of their own. The pair went onto the TaskForce at the same time and were read while the dead disks waited. Two streams instead of one took days off the job, and it meant no disk in the set was signed off on assumption.
The logs put a date on the first disk to go
Both casualties took a matched head stack and started reading again. What the logs showed then rearranged the case: the noisy bay had in fact left the array back in January, putting its contents nine months out of date — an earlier version of the volume, not the one the crash interrupted. The disk that failed most recently held the state that mattered, and the damage on it sat in bands we could work around.
Build it from three images and drop the January disk
Stripe size, the order of the members and the direction parity turns were read off the array's own metadata, not assumed. The build then ran on the three current images, with the January dropout kept out of it: blend blocks written months apart and you manufacture corruption convincing enough to pass a check. The sectors the newer disk refused to give up lay in areas the filesystem had never used.
Signing it off.
The volume mounted at the first attempt. Drawings, casting records and job books were matched to the shop's own order numbers before fresh disks went into the post. The box now lives in the office, clear of the grit, with its warning emails switched back on.
Pages people often read next.
The RAID & NAS jobs.
Is that what yours is doing?
Power it down, get it to us, and hold off on any decision until the diagnosis says what can still be read.