NAS Storage Pool Degraded: Recovery Guide

A degraded storage pool is not a NAS UI glitch. It reflects a failure in the underlying RAID layer that the NAS operating system manages on your behalf. The pool has lost one or more member drives and is operating on parity or mirror redundancy alone.

Consumer NAS units from Synology, QNAP, and NETGEAR do not use dedicated hardware RAID controllers. They run Linux-based operating systems that manage drives using software RAID (mdadm), Logical Volume Management (LVM), and a filesystem layer (Btrfs, EXT4, or ZFS). When the NAS web interface shows "Storage Pool Degraded," it means the mdadm or ZFS array has detected that a member drive is missing, unresponsive, or returning I/O errors.

Hardware RAID (Dell PERC, HP SmartArray, LSI MegaRAID): A dedicated physical controller card with its own ASIC manages parity calculation, drive abstraction, and rebuild operations independently of the host operating system. The controller has its own firmware, cache, and battery backup.
mdadm (Software RAID on Synology, QNAP, ReadyNAS): The Linux kernel's software RAID layer. Manages drive redundancy using the host CPU and system RAM. Each member drive stores an mdadm superblock containing the array UUID, RAID level, chunk size, and device role. No dedicated hardware.
Storage Pool (LVM layer): A logical abstraction layer that sits above the mdadm array. LVM allows dynamic volume sizing, thin provisioning, and multiple filesystems on a single underlying RAID array. Degradation at the mdadm level cascades upward through LVM to the filesystem.
Filesystem (Btrfs, EXT4, or ZFS): The top layer where user data and metadata reside. Btrfs (Synology default since DSM 6.0) provides copy-on-write and checksumming. EXT4 provides traditional journaling. ZFS (QNAP QuTS hero, TrueNAS) manages its own redundancy outside mdadm.

Storage Pool Architecture by NAS Platform

Each NAS manufacturer implements storage pools differently. The layers between the raw drives and your data affect which recovery tools work and which actions cause permanent damage.

Synology DSM 7.x (SHR, SHR-2, RAID 5/6)

Synology Hybrid RAID (SHR) partitions each drive into slices and builds standard mdadm arrays across matching slice groups. These arrays feed into LVM2 volume groups, and the logical volume is formatted with Btrfs or EXT4. A degraded storage pool means at least one mdadm array has lost a member. If the pool uses SHR with mixed-capacity drives, multiple mdadm arrays exist; a failure in any one of them takes the entire LVM volume offline. DSM's "Repair" button initiates an mdadm rebuild, which reads every sector of every surviving drive.

QNAP QTS 5.x (mdadm + LVM)

QNAP QTS uses a similar architecture to Synology: mdadm for RAID, LVM for volume management, and EXT4 for the filesystem. QNAP's Storage & Snapshots Manager presents the pool status as Degraded, Warning, or Error. The "Manage" menu offers options to replace the failed drive and rebuild. On QTS, a forced rebuild on a pool containing a second weak drive results in the same cascading failure as any mdadm rebuild. QNAP's QuTS hero variant uses ZFS instead of mdadm, which changes the recovery methodology entirely.

NETGEAR ReadyNAS (Flex-RAID / X-RAID2)

ReadyNAS uses X-RAID2 (automatic expansion) or Flex-RAID (manual configuration). Both sit on top of Linux mdadm. When a drive fails, ReadyNAS OS marks the volume as degraded and may auto-rebuild if a hot spare is configured. X-RAID2 adds complexity by automatically repartitioning drives when larger replacements are added, which can corrupt mdadm superblocks if the process is interrupted by a power loss or a second drive failure.

Repair Button Risks on a Degraded Storage Pool

Every NAS manufacturer's web interface offers a Repair or Rebuild option when a storage pool degrades. This button triggers an mdadm rebuild, which is the single most dangerous operation you can perform on a degraded array containing irreplaceable data.

1.Full-disk sequential read of all surviving drives. The rebuild reads every sector of every surviving member to recalculate parity data for the replacement drive. On a 4-drive RAID 5 with 8TB drives, this means reading 24TB under sustained sequential I/O.
2.A single URE kills the rebuild. If any surviving drive encounters an Unrecoverable Read Error during this full-disk scan, the rebuild fails. On consumer drives rated at 10¹⁴ URE per bits read, the probability of hitting a URE during a multi-terabyte rebuild is non-trivial.
3.Batch-failure correlation. NAS drives purchased together are from the same manufacturing batch. They share the same wear profile. If one drive from a batch fails after 4 years, the remaining drives in that batch are statistically more likely to fail under the increased load of a rebuild.
4.Rebuild duration exceeds safe operating windows. Rebuilding a parity array with 8TB+ drives can take 24 to 48 hours. The array runs with zero fault tolerance for the entire duration.

Do not click Repair, Rebuild, or Reinitialize. Power down the NAS. Remove the drives. Label each drive with its bay number. If the data is irreplaceable, send the drives for professional NAS recovery with write-blocked imaging and offline array reconstruction.

SMR Drives and NAS Storage Pool Rebuilds

Shingled Magnetic Recording (SMR) drives are a common cause of storage pool degradation and rebuild failures in NAS environments. Certain WD Red (EFAX suffix) and Seagate Barracuda models use SMR technology, which is incompatible with the sustained write patterns of RAID rebuild operations.

SMR drives overlap recording tracks like roof shingles to increase areal density. Writing to an SMR drive requires rewriting adjacent tracks, which triggers background zone garbage collection. During normal desktop use, this delay is imperceptible. During a RAID rebuild, the sustained sequential writes overwhelm the SMR translation layer.

●NAS controllers enforce TLER (Time-Limited Error Recovery) timeouts, typically 7 to 8 seconds. If a drive does not respond within this window, the controller marks it as failed.
●SMR garbage collection pauses can exceed the TLER threshold during sustained writes, causing the NAS to drop a functioning SMR drive from the array.
●This creates a false failure: the drive is mechanically healthy, but the NAS has ejected it due to timeout. The pool degrades further.

SMR rebuild stall pattern: SMR drives (such as the WD Red EFAX series) in RAID 5 configurations are prone to rebuild stalls. During a rebuild, the sustained sequential writes trigger SMR garbage collection, which causes TLER timeouts. The NAS firmware interprets these timeouts as drive failures and drops the replacement drive from the array. The pool then shows two failed members and enters a crashed state. Data that was recoverable via offline imaging in the original degraded state is now at higher risk due to the partial rebuild writes.

NVMe SSD Cache Pools and Storage Pool Degradation

Modern NAS units support M.2 NVMe SSDs as read/write cache pools. When a cache SSD fails while holding dirty (unflushed) data, the primary HDD storage pool can become inaccessible even if all HDD members are healthy.

1.Synology DSM 7.x and QNAP QTS 5.x allow read/write cache acceleration using paired NVMe SSDs. In write-cache mode, incoming writes land on the NVMe tier first and are flushed to the HDD pool in the background.
2.If an NVMe cache drive fails before dirty data is flushed, the Btrfs or EXT4 filesystem on the HDD pool contains references to data blocks that only existed in the cache. The filesystem cannot mount.
3.Many NVMe SSDs use controller-managed FTL mappings and wear-leveling tables that are tied to the specific controller SoC. Chip-off extraction of the NAND yields raw pages without the FTL context needed to reconstruct files. Recovery requires restoring the SSD controller to a functional state through board-level repair or firmware intervention.

SSD cache failure impact: If a read/write SSD cache drive develops a controller failure, the NAS marks the cache as degraded and the primary HDD pool as inaccessible. The Btrfs filesystem tree references dirty blocks that were never committed to the HDD tier. The HDD drives may be mechanically healthy, but the volume cannot mount until the cache data is recovered or the filesystem is reconstructed without the cached blocks.

Safe Response to a Degraded Storage Pool

If the storage pool contains data you need, the correct sequence is: stop the NAS from making changes, image every drive, then attempt array reconstruction offline. The original drives should not be written to at any point.

1.Power down the NAS. Use the DSM/QTS/ReadyNAS web interface to shut down cleanly if accessible. If the interface is unresponsive, hold the power button for a clean shutdown. Do not click Repair, Rebuild, or Reinitialize.
2.Label each drive with its bay number. Bay order matters for mdadm superblock matching. Photograph the drive tray layout before removing drives.
3.Check SMART data on each drive. Connect each drive to a Linux workstation with a write-blocker. Run smartctl -a /dev/sdX and check Reallocated_Sector_Ct, Current_Pending_Sector, and Offline_Uncorrectable. Any non-zero values indicate physical degradation.
4.Image each drive. Create sector-level clones using ddrescue to separate destination drives. This preserves the degraded state. Work from the images for all subsequent operations.
5.Examine mdadm superblocks. Run mdadm --examine /dev/sdX2 on each image to read the RAID superblock. This reports the array UUID, RAID level, chunk size, and device roles. Compare event counts across drives to identify desynchronized superblocks.
6.Attempt read-only reassembly. Run mdadm --assemble --readonly on the images. If the array assembles, mount the Btrfs or EXT4 filesystem read-only and copy data to a new destination.

If you are not comfortable working with mdadm, LVM, and Btrfs at the command line, or if the drives have physical symptoms (clicking, not spinning, not detected), professional NAS data recovery with write-blocked imaging and offline reconstruction is the lower-risk path. We image drives using PC-3000 and DeepSpar Disk Imager in a 0.02µm ULPA-filtered clean bench.

How We Recover Degraded NAS Storage Pools

Our lab receives NAS drives from Synology, QNAP, NETGEAR, Buffalo, ASUSTOR, TerraMaster, and Unraid systems. The recovery process separates physical drive stabilization from logical array reconstruction.

Physical Drive Work

●Head swaps on drives with clicking, grinding, or non-spinning symptoms. Performed in our 0.02µm ULPA laminar flow bench.
●Firmware repair on drives that are detected but return I/O errors. PC-3000 terminal access to the drive's service area for module correction.
●Sector-level imaging with head maps and read retries. Drives with bad sectors are imaged using PC-3000's selective head imaging to extract maximum data before the drive degrades further.

Logical Array Reconstruction

●Parse mdadm superblocks from each member image to identify array geometry, chunk size, and drive roles.
●Reconstruct LVM physical volume headers and volume group metadata from the assembled array image.
●Mount Btrfs, EXT4, or ZFS filesystem in read-only mode. Extract data to a destination drive. If the filesystem is damaged, file carving recovers data by signature.

All work is performed in-house at our Austin, TX lab. Single location. No franchises. No outsourcing. No data, no recovery fee.

Frequently Asked Questions

What does storage pool degraded mean on a NAS?

A degraded storage pool means one or more member drives have failed, disconnected, or started reporting errors. The NAS operating system (Synology DSM, QNAP QTS, NETGEAR ReadyNAS OS) detects the underlying mdadm or ZFS array has lost a member and flags the pool as degraded. The array is still operational using parity or mirror redundancy, but it has zero remaining fault tolerance in RAID 5 configurations. A second drive failure during this state is catastrophic.

Is it safe to click Repair on a degraded storage pool?

No. Clicking Repair in the NAS web interface initiates a RAID rebuild. This forces a full read of every sector on every surviving drive to recalculate parity. On large drives (4TB and above), this sustained I/O places enough mechanical stress on aging drives to cause a secondary failure. If any surviving drive encounters an Unrecoverable Read Error (URE) during the rebuild, the entire array fails permanently. Power down the NAS and image the drives before attempting any rebuild.

What happens if I reinitialize a degraded storage pool?

Reinitializing a storage pool destroys the existing mdadm superblocks, LVM metadata, and filesystem structures on every member drive. This is equivalent to formatting. All data on the pool is permanently lost. Some NAS interfaces present reinitialization as a repair option when the pool is degraded. It is not a repair; it creates a new, empty pool.

Can you recover data if two drives failed in a NAS RAID 5?

Recovery depends on the failure timeline and drive condition. If both drives failed simultaneously, the array has no surviving parity path and recovery requires imaging all members and attempting partial reconstruction from whatever sectors remain readable. If one drive failed first and the second failed during a rebuild attempt, the pre-rebuild state of the surviving drives may still contain valid parity. We image every member with write-blockers and reconstruct the array offline to maximize recovery.

Can I rebuild a degraded NAS pool using WD Red SMR drives?

SMR (Shingled Magnetic Recording) drives cause rebuild failures in NAS environments. During a rebuild, the NAS writes reconstructed parity data to the replacement drive. SMR drives handle writes by stacking tracks in overlapping shingles, which requires background zone garbage collection. This garbage collection causes response delays that exceed the NAS controller's TLER (Time-Limited Error Recovery) threshold. The NAS interprets the delay as a drive failure and drops the replacement drive mid-rebuild, failing the entire array.

How much does NAS storage pool recovery cost?

NAS recovery is priced per member drive based on the work required. Logical recovery (healthy drives, damaged metadata) starts at $250 (file system recovery tier). Mechanical recovery (head swaps, motor failure) on individual members follows our standard HDD pricing: firmware repair $600 to $900, head swap $1,200 to $1,500. If no data is recovered, you owe nothing. We publish pricing tiers at rossmanngroup.com/pricing.