The email from a Synology in a Prestonpans back office lands overnight: Volume 1 is now in degraded mode. A drive has failed. Please replace the drive to begin repair. By the time the owner sees it over morning coffee, the box has been sat there flashing amber for ten hours, and the temptation is the obvious one — pop the failed drive out, slot the spare in, click Repair, and go about the day. Do not do that yet. On a home or small-business NAS, the rebuild is often the moment you lose the data, not the moment you save it.
This is a straight-talking guide for people running a Synology, QNAP, WD My Cloud, TerraMaster or similar box out of a house or small unit in Prestonpans, Cockenzie, Longniddry or Tranent. Everything below is what we actually do on the bench when a NAS lands with us, and what a genuine data recovery service will always insist on before anyone touches the array.
What "Rebuild" Actually Does — and Why That is the Risk
On a two-bay NAS running RAID-1 (mirroring), or a four-bay running RAID-5 or SHR, the rebuild does the same thing at heart. It walks every single block on the surviving drives from the start of the disk to the end, reads it, calculates what the new drive should contain, and writes that block across. On a 4 TB volume that is around 8 billion sectors, read in order, at 100% duty cycle, for anywhere between six and thirty hours.
That is a workload the surviving drive has probably not seen in years. Day-to-day, a home NAS reads about the same 5% of its capacity — the recent photos, the current spreadsheets, last month's invoices. The other 95% has been sitting untouched. A rebuild forces the drive to read every square millimetre of platter, including the parts with slow-growing bad sectors that were quietly failing without ever being touched.
Same-Batch Failure: The Statistic Nobody Mentions
Here is the part most NAS owners are never told. When you bought the unit, the two or four drives inside came from the same reel of stock at the wholesaler. They have the same manufacturing date, the same firmware revision, and — if they have sat in the same NAS for four years — the same power-on hours, the same temperature curve, and the same duty cycle. Statistically, drives from the same batch fail on curves that look nearly identical.
What this means in practice is that a NAS drive failure is very rarely a lone event. It is far more often the first drive of a set to cross the line. On the bench we see the same pattern repeatedly: a customer swaps the failed drive, starts the rebuild, and the second drive throws unrecoverable read errors somewhere in the middle of the process. On a RAID-1 the array falls over and the volume goes offline. On a RAID-5 or SHR-1 a single unrecoverable read during rebuild takes the whole array with it. You now have two dead drives and no volume.
Image the Surviving Drive Before You Do Anything Else
The single change that turns a scary situation into a routine one is this: before you rebuild, take a bit-for-bit image of every remaining drive. Not a file copy — a full block-level image using a tool that reads gently and retries around bad sectors without hammering them. On the bench we use Deepspar or ddrescue on Linux for exactly this. The image becomes your insurance: if the rebuild does trigger the second failure, we still have the volume in a file, and we can assemble it in software after the fact.
For a home NAS this normally means shutting the box down, removing the drives, and imaging each one on a workshop rig with a proper SATA dock. Most consumer NAS units — Synology in particular — use standard Linux mdadm + LVM + Btrfs or ext4 under the bonnet, which means the images can be mounted read-only on a Linux workbench without the original NAS ever booting again. That matters if the NAS unit itself is what has actually failed — a fried power supply or a dead motherboard on the box is a much smaller problem than most people think, provided the drives inside are healthy.
What To Do Right Now (In Order)
If you have a degraded NAS in Prestonpans right now, the correct order of operations is:
First, do not start the rebuild. Do not click Repair. Do not "just let it run overnight and see". Second, do not put the failed drive back in the caddy and see if it comes back — a marginal drive that has been failed by the NAS controller is often minutes from complete failure, and every additional spin-up loses more sectors. Third, shut the NAS down cleanly through its web interface. Fourth, mark each drive with the bay number it came from — masking tape and a Sharpie is fine — and bring the whole set in for triage.
What we then do is image the surviving drives cleanly, inspect the failed drive to see whether it can be imaged at all (many can, with the right hardware), and only then talk about rebuild strategy. Sometimes the right answer is a rebuild on the original NAS with a fresh replacement drive. Sometimes it is a virtual reassembly of the array on a workbench, then a fresh copy back onto a clean new set of drives. That call cannot be made honestly until the images exist.
Recovering a Failed Synology, QNAP or WD My Cloud
Different vendors, similar internals. Synology's volumes are Btrfs or ext4 sitting on top of a Linux mdadm array in almost every current model, and they can be reassembled outside a Synology box with the right commands. QNAP is much the same story with a slightly different volume manager. WD My Cloud singles are a plain ext4 drive with a WD-branded Debian on top — often the fastest recovery in the range, because there is no array to reassemble at all.
The one to be careful with is any older ReadyNAS X-RAID array, or any home-brand NAS that shipped its own proprietary volume layout. Those need the vendor's own recovery utility, or a controlled reassembly by someone who knows the layout. Our wider hard drive recovery guide covers single-drive external units in more detail if that is closer to what you have; the clicking external drive guide is worth reading if any of the NAS drives themselves are making noises.
When Recovery Is Straightforward — and When It Isn't
Straightforward: one drive failed with a controller-board fault or a bad-sector count that crossed the NAS's threshold, the other drives are healthy, and imaging captures everything in a single pass. Recovery here is essentially a copy job onto fresh drives and a re-import into a rebuilt NAS. Most of the NAS calls we take from East Lothian small businesses land in this bucket.
Harder: the failed drive is silent — no spin, no click — because a component on its controller board has burnt out. That is a job for our microsoldering team, who can swap the board with a matching donor and — critically — transfer the drive's unique adaptive data across so it reads its own platters. On a mirrored RAID-1 this is often optional because the other disk holds the same data; on a RAID-5 with a second drive throwing errors, board-level work on the "failed" drive can be the difference between a full recovery and a partial one.
Harder still: someone has already tried to rebuild, the second drive has failed halfway through, and the array is offline. This is still often recoverable — but recovery now means reading each surviving drive to a file, working out where the rebuild got to and what it overwrote, and reassembling the volume from the parts that were not touched. That is slow, careful work and it is the case that comes in most weeks from someone who "just wanted to see if it would come back".
A Recent Prestonpans Example
A small graphic-design outfit off Ayres Wynd brought in a four-bay Synology at the end of June. Two of the drives showed as failed in DSM — one had been failed for months and quietly ignored, the second had failed the night before. The owner had not started a rebuild only because DSM would not let him with two failed drives at once; if it had been one, he would have. The array held about ten years of client files and the current job in progress.
Imaging the two "failed" drives took most of a day between them. The one from months ago was in fact worse than the recent failure — around eleven thousand unrecoverable sectors, all in a band near the middle of the disk. The recent failure had five bad sectors, all in one small region. Between the two images and the two healthy drives, we had four full copies of every stripe in the array. A virtual reassembly on the bench produced the volume intact; a fresh set of four drives went back into a rebuilt Synology and their files copied across overnight. Total loss: none. Had a rebuild been started, the second drive's small bad region would almost certainly have taken the array down, and the older drive's eleven thousand bad sectors would have made recovery a much messier job than it needed to be.
Backups That a Rebuild Would Not Save
A NAS on its own is not a backup, even when it is a RAID array. RAID protects against a drive failing; it does not protect against a rebuild going wrong, ransomware writing to every share overnight, a lightning strike on the power supply, or someone deleting the wrong folder. The 3-2-1 rule stands here: three copies, on two different media types, with one off-site. On a small-business NAS in East Lothian that usually looks like the NAS itself as the working copy, a scheduled Hyper Backup or Snapshot to a rotating USB drive that lives elsewhere, and a cloud copy to Backblaze B2 or Wasabi.
For businesses that cannot bring the NAS itself in — because it is running the office — our business IT support team can visit, take images on-site, and set the box up in a safer configuration with a proper backup schedule. For a same-day drop-off from Prestonpans, our workshop is off the A1 at Sighthill, about twenty-five minutes by car; local support in East Lothian is covered by our Prestonpans data recovery page.
If a NAS drive fails, the temptation is speed. The right move is slow. Image first, decide second, rebuild last — and if you are not sure which stage you are at, unplug it and phone before the rebuild begins.
Last updated: 6 August 2026