The short answer: The Repair button in Synology DSM and Rebuild RAID Group in QNAP QTS are safe only when three things are true at the same time: you have a backup that someone has recently restored from successfully; you know exactly which disk dropped out and why; and the remaining disks show neither errors in the logs nor increasing bad-sector counts. If any one of these conditions is not met, a rebuild is not a repair—it is the longest sustained write operation the array will ever experience, performed directly on the data you are trying to protect.
The dividing line is not between brands, but between „still working„ and „already failed"
People copy error messages into search engines word for word because NAS interfaces often remain in English even in Czech companies: storage pool degraded, storage pool crashed, volume crashed, and system partition failed on Synology; RAID group degraded, volume read-only, volume not active, and storage pool inactive on QNAP. They look like two different sets of problems. In reality, they describe the same dividing line, and both brands draw it in the same place.
Synology defines it clearly: Degraded means that one or more disks are faulty, but the array remains accessible and no data has been lost—Repair may return it to a healthy state. Crashed means that the user can no longer repair the array, usually because too many disks have failed and data integrity cannot be guaranteed.
QNAP uses different terminology for the same line. Read-Only is not a milder form of degradation—it is a state in which QTS has itself restricted writes because something is wrong in the storage pool, and some RAID groups may already be Not Active.
In practical terms: degraded is a warning; crashed and read-only are incidents. Only one click separates them—Repair on an array where a second disk is already failing silently.
Two separate pages explain exactly what each message means and the safer next step for each one: Storage Pool Degraded, Volume Crashed, and System Partition Failed messages in DSM and RAID Group Degraded, Read-Only, and Volume not active states in QTS. This article focuses on what they have in common: how to verify the three decisive facts before clicking anything.
Three questions that determine what to do—and where to find the answers in DSM and QTS
Before doing anything else, save screenshots of Storage Manager or Storage & Snapshots, the disk list with models and slot numbers, the exact error message, and the relevant log entries. Without them, you may later be left guessing what the system looked like before anyone intervened.
1. Has the backup been verified, or is it merely green? A green job status tells you that the job finished—not that its data can be restored. Hyper Backup’s integrity check verifies that the task can continue and that the backup can be restored; it does not transfer any data. That is not a restore test. The question that matters is: when did someone last retrieve a real file from that backup or rebuild a machine from it?
2. Do you know which disk dropped out and why? In DSM, check the specific disk in Storage Manager—Health Info, including Warning or Critical status and the counts of bad, reallocated, and pending sectors—and review Log Center. In QTS, use Storage & Snapshots, IHM status, and the system logs. Look for I/O errors, bus resets, and repeated disconnections of the same slot. Beware of a common trap: S.M.A.R.T. remains green until the disk itself admits defeat—degradation is often easier to identify from rising reallocation counts and latency than from the overall verdict.
3. Are the other disks genuinely clean? This is the most important question and also the one people tend to skip because all attention is drawn to the disk that dropped out. Yet a rebuild affects every remaining disk: it continuously reads enormous amounts of data from them and writes the reconstructed data to the replacement. Rebuilding a four-disk RAID 5 made from 4 TB disks requires roughly 12 TB of reads; with 8 TB disks, it is about 24 TB. Consumer-drive manufacturers specify a lower bound of one unrecoverable sector per 10^14 bits read, or about 12.5 TB. That figure is a conservative specification, not a prediction of data loss, but it supports one indisputable conclusion: a rebuild is statistically the riskiest operation an array will undergo.
All three checks are read-only. None of them writes anything, which is why spending half an hour on them is worthwhile.
What each button actually writes
A NAS interface offers recovery functions automatically when a failure occurs. Their presence in the GUI is not a recommendation tailored to your situation—they are standard functions intended for standard maintenance scenarios.
| Interface action | What it actually does to the disks | When it is appropriate |
|---|---|---|
| Repair / Rebuild RAID Group | Continuously reads from every surviving disk and writes to the new one; rewrites parity that may be needed for recovery | Only when all three conditions above are met |
| Recover RAID (QuTS hero) | Attempts to return temporarily disconnected disks to the array | Only for a disk removed and immediately returned to the same bay—not for a disk that dropped out because of a fault |
| Create / Initialize / new volume | Creates an empty array and destroys mdadm superblocks, LVM metadata, and file-system structures | Never when the data matters |
Check File System, fsck, btrfs check --repair, zpool scrub | Writes to file-system metadata. The tool may interpret corrupted parity as file-system damage and delete valid entries | Not on a broken array |
| Moving disks between bays | On most platforms, triggers an automatic rebuild attempt or metadata write | Never without first recording the disk order |
| Switching QTS ↔ QuTS hero | QNAP states it plainly: „Switching to QuTS hero will erase all data on your NAS." This applies in both directions | Only with a complete and verified backup |
| Connecting NAS disks to Windows | Windows cannot mount ext4, Btrfs, or XFS and will offer to „initialize disk," overwriting the partition table and RAID metadata | Never |
Btrfs deserves special mention because an in-place „repair" is particularly treacherous: it rewrites the generation roots of its copy-on-write trees—the very structures on which subsequent recovery depends. Metadata on a damaged volume should be read with btrfs-restore, not repaired by mounting the volume.
There is one more issue that recovery labs describe as the most common and destructive mistake of all: forcing a rebuild without being certain which disk is actually faulty. Not an exotic intervention or a command-line operation—just an ordinary click on a button offered by the interface.
Five situations where „degraded" does not mean a faulty disk
The model of „a disk dropped out, so I will replace it" fits one specific scenario. Here are five cases where it does not.
- A healthy disk dropped out because of a timeout. A desktop SATA disk lacks time-limited error recovery and may spend tens of seconds or as long as two minutes repeatedly trying to read a weak sector. A controller that waits only 7 to 30 seconds interprets this as a failure and ejects the disk. NAS drives use TLER, ERC, or CCTL and give up after roughly seven seconds. The catch is that the disk may then pass a standalone test without any errors.
- The array contains an SMR disk. A rebuild subjects it to a long, continuous write. Once its cache area fills up, it begins rewriting entire bands using real-time read-modify-write operations, and throughput drops to only a few MB/s. The controller exceeds its timeout and ejects the disk—repeated attempts only make the situation worse.
- An NVMe cache SSD has failed. The cache contains uncommitted writes destined for the array; it is not a disposable copy. If it dies, the entire Btrfs volume may crash even though all mechanical disks are healthy.
- There was a power outage. Power disappears between writing data and updating the parity block, leaving the array inconsistent. The dangerous part is that the NAS may then boot and appear normal, while the backup catalogue, database, or virtual-machine image remains damaged.
- The event counters in the mdadm superblocks do not match. The array refuses to assemble from disks it considers outdated even though they still contain the data. Running
mdadm --assemble --forcewithout understanding the event counts, offsets, and disk order is a gamble, not a repair.
The common denominator is simple: a rebuild is not the solution in any of these five situations. Yet the interface will readily offer one in all five.
Two documented cases: planned maintenance is the most dangerous moment
Synology DS2015xs, RAID 6, six 6 TB disks. The array used five WD60EFRX drives (CMR) and one WD60EFAX drive (SMR), which had been installed as a replacement for a failed CMR disk. The new drive began reporting errors, performance dropped to an unusable level, the NAS could no longer shut down or restart properly, and eventually it would not power on at all. The laboratory that handled the case summarised it in a sentence worth reading twice: „NAS truly did not report any failures or outages." The error records were present in the logs. The user received no warning.
Netgear ReadyNAS, X-RAID on Btrfs. The scenario was an online capacity expansion: three 3 TB disks were progressively replaced with 6 TB disks, with the array rebuilding after each replacement. A newly inserted 6 TB disk began reporting ATA errors halfway through a rebuild, and a second disk also dropped out of the array—even though that second disk subsequently passed a standalone test without errors. The incomplete rebuild damaged both the metadata and the file system.
Both cases lead to the same conclusion: the most dangerous moment in a NAS system’s life is not a failure, but planned maintenance—replacing a disk, expanding capacity, or migrating data. The monitoring system a company relies on may report nothing at all, so it is worth checking something as basic as whether DSM or QTS notifications are being sent to an address that someone actually reads.
When to stop clicking immediately—no exceptions
- The status is crashed, inactive, or read-only.
- More than one disk is reporting errors.
- A disk is clicking, repeatedly disappearing, or showing increasing pending and reallocated sector counts.
- Repair or rebuild has already run once and did not finish—or it finished without improving the status.
- Someone has already tried a reset, reinstalled the system, replaced multiple disks, or moved disks between slots.
- The data exists only here.
In these situations, another click is not a repair attempt; it is a write to the only remaining copy. Powered-down data is stable. If you cannot extract the data even after shutting down the NAS and connecting the disks elsewhere, the article on how to retrieve data when a NAS dies explains the available options and their risks.
What to prepare before calling someone
- The NAS model and system version (DSM, QTS, or QuTS hero).
- The number of disks, their exact models and capacities, and their bay order.
- The array type (RAID 1/5/6/10, SHR-1, SHR-2, or X-RAID) and file system (ext4, Btrfs, or ZFS).
- When everything last worked and what happened immediately beforehand—a disk replacement, power outage, update, or migration.
- What has already been tried. Most importantly, whether anyone ran a rebuild, initialization, file-system check, or connected the disks to Windows. This is not about assigning blame; it determines what may still remain on the disks.
- Whether any backup exists and when someone last restored from it.
Frequently asked questions
DSM offers Repair. Does that not mean it is safe?
No. Repair is a standard function for a standard situation: a degraded array where it is clear which disk dropped out and the remaining disks are healthy. The interface does not know the state of your backups or what happened to the array last week. Offering the button is not a risk assessment.
The array is degraded, but the shared folders are accessible. Can I copy the data?
If the disks do not sound mechanically unhealthy and the logs contain no errors from additional disks, it makes sense to retrieve the most important folders. Do not start a complete backup that will run for many hours—reading the entire surface of an unstable array adds stress and can accelerate the failure you are trying to avoid. Stop backup jobs, indexing, camera recording, and scheduled SMART tests first.
The replaced disk tested as healthy. Can I put it back?
Physically, yes, but that does not answer the question of why it dropped out. A disk ejected from an array because of a timeout or SMR firmware behaviour may pass a standalone test without errors and then behave exactly as before when returned to the array.
Will the recovery software I use on Windows help?
Not with a multi-disk array. Programs of this kind scan one disk at a time and cannot reconstruct the array, so they cannot recover a file distributed across multiple stripes.
Is your array degraded, crashed, or read-only, and are you worried about clicking the wrong option? Send us a screenshot from DSM or QTS and describe what has already been done. We will tell you whether this is still a routine service operation or whether it is safer to shut down the NAS and work from disk images. The service page explains how RAID and NAS data recovery works, including what happens to the original disks.
Sources
- Synology: Repair and Storage Pool (definitions of Degraded and Crashed) — kb.synology.com
- Synology: What can I do if one of my volumes crashed? — kb.synology.com
- QNAP QTS 5.2: Storage pool status (Read-Only, Not Active, Inactive) — docs.qnap.com
- QNAP QTS 5.1: Recovering a RAID Group with a Degraded status — docs.qnap.com
- QNAP: Can I switch my NAS OS? (switching QTS ↔ QuTS hero erases data) — qnap.com
- Rossmann Repair Group: What Happens During a NAS Crash (Btrfs, NVMe cache,
btrfs-restore) — rossmanngroup.com - Rossmann Repair Group: Why Rebuilding a Degraded RAID Destroys Data — rossmanngroup.com
- SmallNetBuilder: The Seven Biggest Mistakes When Attempting Data Recovery — smallnetbuilder.com
- Wikipedia: Error recovery control (TLER, ERC, CCTL) — en.wikipedia.org
- EXALAB: RAID data recovery after an HDD failure in a NAS (Synology DS2015xs case) — exalab.cz
- EXALAB: Data recovery from a Netgear NAS after RAID 5 failure (X-RAID and Btrfs case) — exalab.cz
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).