Casebook entry · NAS & RAID · EDR-2025-2341
An Amber Warning Since Spring, a Click by August.
A Marsh Barton joinery firm lost its four-bay Synology in the August heat: the volume just says crashed
. One disk had worn an amber warning since spring; a second was now clicking. The request that came with the box — get it running first, we'll sort copies out after
— was the one we would not honour.
Sound familiar? Talk to us.
0800 6890668
In plain English.
RAID 5 keeps one disk's worth of insurance, spread thin across the set. Lose a member and every stripe can still be solved; lose two and the sums run out of knowns. Powering the box up to 'get it running' would have piled load onto two elderly survivors while inviting a crashed volume to write fresh metadata over the very structures any reconstruction depends on. So the box stayed off. In this trade the copies are not the cautious version of the plan — they are the plan.
The tools this job took.
See how your case runs →| System | The part it played | Why we rate it |
|---|---|---|
| DeepSpar Disk Imager 4 | Transplants for both failed members, the newer casualty read first | Images by head map — timeouts, resets and power-cycling managed per head |
| Atola TaskForce 2 | Copied the two healthy disks in parallel while the head work continued | Clones multiple array members at once, shrinking a week's imaging into days |
| UFS Explorer RAID Recovery | Read the mdadm metadata and raised the volume across the images | Reads NAS volume managers as the layered systems they are, not one flat array |
On the bench.
Image the healthy pair as carefully as the dead
Disks that ride out a degraded array rarely do so unmarked, and both survivors were nursing small clutches of pending sectors of their own. They went onto the TaskForce together, imaged side by side while the mechanical work ran at the bench — parallel capture that took days off the timetable and left no member of the set untrusted or uncopied.
Two transplants — and a calendar hidden away in the SMART logs
Both casualties took matched donor stacks and read again. Then the logs rewrote the story: the amber disk had left the array in April, its contents four months stale — the volume as it once was, not as it ended. The freshly failed disk was the copy that mattered; its damage sat in defined bands, and those waited until all else was secure.
Solve the stripes on the bench, with the stale disk stood down
Disk order, stripe size and the parity rotation came straight from the array's own metadata. The volume was then assembled from the three current images — the April dropout excluded, because blending months-old blocks into a reconstruction is how phantom corruption gets built in. The few sectors the fresh casualty never yielded fell where the filesystem held nothing live.
How it ended.
The volume mounted first time. Drawings, cutting lists and accounts were ticked off against the firm's own project list, the data went back on a new set of disks — and the NAS now emails somebody the moment a light turns amber.
More like this in the casebook.
More from RAID & NAS.
Sound like your drive?
Every case here points the same way: power the device down, take the free diagnosis, then make your decision.