NAS & RAID · job sheet · MHD-2025-6341
Two Members Down in a Four-Bay Array.
A staircase joinery in Boyn Hill ran a four-bay Synology from a shelf where the fan filled slowly with sawdust. One bay had reported bad sectors since Christmas, the warnings dismissed to stop the emails arriving. When a job list refused to open, the unit was switched off and on. It returned with volume crashed
. The note that came with it, clone the failing disk in and rebuild
, we declined.
Much the same fault? Call us.
0800 6890668
In everyday terms.
Parity in a RAID 5 amounts to one disk's worth of cover, thinned out across the whole set. Lose a single member and every stripe can still be worked out; lose a second and there are more unknowns than equations. Switching the box on to see what it might do would have leaned on two survivors already past their best, and given a crashed volume the chance to stamp new metadata across the exact structures a reconstruction depends on reading. The unit therefore stayed off, and the clone-and-rebuild instruction was declined in writing. On a job like this, imaging is not a careful step taken before the real work begins. It is the work.
What the bench used here.
How a job is handled →| Tool | Why we used it | What it brings |
|---|---|---|
| DeepSpar Disk Imager 4 | Fresh head stacks into both failed members, the newer casualty imaged first | Head map first, then head-by-head reads, holding resets, timeouts and the power line steady |
| Atola TaskForce 2 | Copied the two survivors in parallel while the bench work continued | Parallel imaging across the whole set, so the copying stage runs in days, not weeks |
| UFS Explorer RAID Recovery | Read the mdadm superblocks and assembled the volume across the images | Understands the layers a NAS stacks on top of its disks, not just the array |
The lab work.
Handle the working disks as gently as the dead ones
A disk that has been carrying a degraded array seldom emerges unmarked, and each survivor had picked up a small crop of pending sectors. Both went onto the TaskForce and were copied while bench work on the failed pair carried on. Running the two streams together took days out of the schedule and meant nothing in the set was left uncopied or simply trusted.
Two donor stacks, and a date the SMART log gave away
A matched donor stack went into each casualty and both would read once more. The logs then altered the picture entirely. The disk flagging since Christmas turned out to have left the array in January, which made its contents nine months out of date: the volume as it once stood, not as it stood at the end. The recent failure held the version that counted, and its damage sat within defined bands.
Rebuild it on the bench, with the stale image left out
Stripe size, member order and the direction of parity rotation came from the array's own metadata rather than from assumption. The rebuild took the three sound images and left the January dropout out of it, because mixing blocks months apart into a reconstruction is exactly how believable corruption gets made. The few sectors the recent casualty never gave up lay in space the filesystem had not allocated.
How the job closed.
The volume mounted at the first attempt. Every drawing, cutting list and ledger was checked against the firm's own job numbers before the fresh disks went out. The NAS has since moved into the office, where the fan has clear air and somebody reads the warnings.
More of the jobs we've closed.
Other RAID & NAS jobs.
Does any of that match your case?
Nothing needs deciding until the diagnosis is back: switch the device off, send it in, and let the findings settle it.