A Synology or QNAP NAS reporting a failed drive isn’t a data loss event yet. What usually decides the outcome isn’t the failure itself, but what happens in the hours that follow. A reset that wipes the RAID metadata, a rebuild launched without checking the health of the remaining drives, a file-system check re-run on an already fragile volume — each rushed decision cuts the odds of recovery. Here are the mistakes that most often turn a recoverable failure into permanent loss.
What actually happens when a drive fails
A Synology or QNAP NAS runs on a software RAID array managed by the box’s own operating system (DSM on Synology, QTS or QuTS hero on QNAP). When a drive fails, the NAS drops into degraded mode: it keeps running by recalculating the missing data on the fly, using parity (SHR, RAID 5, RAID 6) or mirrored copies (RAID 1, RAID 10). The volume stays accessible, but the entire load now falls on the surviving drives.
This window of vulnerability is exactly where most permanent losses happen — not because of the original failure, but because of a rushed manipulation afterward. A share of the NAS units that arrive at a lab with data already lost would have been recoverable if no action had been attempted after the failure.
The mistakes that make it worse
- Starting a rebuild with no backup first. Swapping the drive and clicking “Repair” looks simple, but a rebuild forces every surviving drive through a full read of every sector, sometimes over several days. If a second drive already has bad sectors, it can fail mid-rebuild and push the volume from “degraded” to “crashed” — i.e. inaccessible. The right move is to back up whatever is still accessible before starting any rebuild, even though the interface pushes you to repair immediately.
- Confusing a reset with a reformat. On QNAP, several options coexist: a soft reset (keeps the data), a factory reset, and a full reset with volume reformat (destroys the data). On Synology, the equivalent trap is deleting a “crashed” storage pool and recreating a new one on the same drives, thinking it will “repair” the volume — this overwrites the RAID metadata (the mdadm superblock) needed to reconstruct the array.
- Pulling or swapping drives without care. On software RAID (mdadm for DSM and QTS, ZFS for QuTS hero), the physical order of the drives generally doesn’t matter. But the moment a drive is pulled while the NAS is running, the system marks it as missing, and every write from then on creates a sync gap. Reinserting it later triggers a resync, with the risks that carries on drives already under strain — only an immediate reinsertion, with no writes in between, avoids triggering it.
- Using an incompatible replacement drive. Two mistakes come up often: fitting a drive with lower capacity than the other array members (the NAS simply refuses the rebuild), or using an SMR drive in place of a CMR one. SMR drives, optimised for storage density rather than sustained writes, saturate their cache quickly during an intensive RAID rebuild — causing timeouts that can eject the drive mid-operation. Since CMR/SMR isn’t always clearly stated on the box, the exact model should be checked with the manufacturer before any replacement.
- Running a file-system check on a degraded volume. An integrity check (the equivalent of an FSCK or CHKDSK) is harmless on a healthy volume. On a degraded one, it reads missing data as corruption: it can delete directory entries, truncate files, or rewrite metadata trees — irreversible changes that erase exactly the traces a later recovery attempt would need. Btrfs, the default file system on recent Synology models, is particularly sensitive to this.
- Leaving the NAS running in degraded mode and doing nothing. The opposite mistake is just as costly. The remaining drives take on extra load, wearing out faster and raising the odds of a second failure — which is fatal on RAID 5 or SHR-1. The risk isn’t limited to a mechanical failure either: every read in degraded mode forces the system to recalculate the missing data from parity, and an unrecoverable read error (URE) hit during that recalculation permanently loses the block involved.
The special case of encrypted NAS units
When encryption is active, a failure changes nature entirely: the drives can be physically intact and still completely unusable without the key. On Synology DSM, shared-folder encryption relies on an exportable key (.key file); if it was only ever handed to the built-in key manager and never backed up externally, it disappears along with the failed unit. Recent models also offer LUKS-based volume encryption, which follows the same logic. QNAP QTS works in a comparable way, while QuTS hero’s native ZFS encryption adds its own separate key-management layer.
The first question to ask in front of a failed, encrypted NAS is simple: was encryption active, and does the key exist outside the NAS? That single fact shapes the entire recovery strategy and should be shared with a lab from the first contact.
What to actually do
The right course of action depends on data criticality and whether a backup exists. If a recent, verified backup exists, the situation is under control: replace the failed drive and start the rebuild following the manufacturer’s procedure, checking the S.M.A.R.T. status of the surviving drives first. If no usable backup exists, caution comes first: copy whatever is still accessible to an external drive before touching anything else. If the volume is already “crashed” and inaccessible, the safest decision is often to do nothing further — power the NAS down cleanly, label each drive with its original bay number, and contact a specialised lab. Any reset, pool recreation, or rebuild attempted on an already-crashed volume risks overwriting the metadata a recovery would depend on.
When to call in a specialised lab
The more repair attempts made before a unit reaches a lab, the longer, harder, and less certain the recovery becomes — some NAS units received in-lab held data that was fully recoverable at the outset, but arrived after two or three repair attempts had progressively destroyed the volume’s logical structures. Once a NAS or RAID server goes into an error state with critical data and no backup, every extra manipulation reduces the odds of recovery: cutting the power and waiting for a professional diagnosis beats repeated attempts on data with no safety net.
A Synology or QNAP NAS failure is almost never permanent the moment it happens. It usually becomes permanent one or two manipulations later.