NAS Storage Pool Degraded: Recovery Guide

Synology DSM: Degraded still mounts, Volume Crashed does not

On a Synology DiskStation, Degraded and Volume Crashed are two different states. Degraded means the mdadm array is still assembled and running with one member missing. Redundancy is gone, but the volume still mounts and DSM Storage Manager shows the pool and volume as Degraded.

Volume Crashed is the harder state. DSM reports "Volume Crashed" when mdadm can no longer assemble or mount the array, so the volume is offline. Neither state means you should reach for the DSM Repair button first.

Repair triggers a full-disk mdadm rebuild that reads every sector of every surviving member. Consumer drives are rated for about one unrecoverable read error per 10¹⁴ bits read, roughly 12.5 TB. A single URE on a surviving member while rebuilding an already-degraded array halts the rebuild and can crash the pool, so image every surviving member with ddrescue or a PC-3000 through a write-blocker before any Repair.

We reassemble the imaged members offline in read-only mode with Data Extractor Express RAID Edition, then copy the data out. If your SHR or RAID pool is degraded or crashed, mail the drives to our Austin, TX lab. All work is in-house, and there is no fee if there is no data.

QNAP QTS: Inactive is often partition-1 corruption, not a dead drive

On QNAP, an Inactive storage pool or volume is frequently partition-1 configuration-database corruption rather than physical drive failure. QTS stores the configuration database that maps storage pools to their underlying mdadm arrays on partition 1 of the member drives.

A failed firmware update or an interrupted write to the Disk-on-Module can corrupt partition 1. The Storage & Snapshots manager then desynchronizes and reports the pool as empty, uninitialized, or Inactive, even though the user data on partition 3 is intact.

The safe path is a raw clone of every member, followed by manual mdadm assembly, then LVM activation, then ext4 reconstruction, or ZFS reconstruction on QuTS hero. Do not accept an in-place Initialize prompt, which writes a new empty pool over your data.

To read an Inactive pool without an in-place initialize, send your QNAP members to the Austin, TX lab for write-blocked imaging and offline reconstruction.

TrueNAS and FreeNAS: read zpool status before forcing a resilver

On TrueNAS or FreeNAS, the state that matters is what zpool status reports. DEGRADED means the pool is imported and functional but one or more vdev members are degraded, UNAVAIL, or REMOVED, so redundancy is reduced and a resilver may be running.

FAULTED means ZFS has marked a device, or the pool, unusable, typically after repeated I/O errors. A resilver that keeps hitting read errors on a dying member can stall. As an illustrative example, zpool status might show a state of DEGRADED with a single member marked FAULTED beneath the vdev.

ZFS is copy-on-write, so a resilver does not recalculate parity across a stripe the way a hardware RAID 5 rebuild does. The real risk is different: forcing a resilver that reads heavily from a marginal or failing member can push that member into full failure before a complete sector-by-sector image exists. If the pool loses more redundancy than it has, it goes UNAVAIL and will not import.

The safe order is to image the failing member first, then work from the clone. If your pool is DEGRADED or FAULTED, ship the pool disks to our lab and we image before we import.

Unraid: a failed data drive runs in emulated mode, and it does not stripe

Unraid does not stripe data across drives. Each data drive is an independent, complete XFS or Btrfs filesystem, and parity lives on a dedicated drive. That single fact changes what a failed drive means.

When a data drive fails, the array runs in emulated mode. The missing drive's contents are reconstructed on the fly from the parity drive plus the remaining data drives, so your shares stay available while running on reduced redundancy.

Because the surviving data drives hold complete independent filesystems, they can be physically removed and mounted directly on a standard Linux workstation to pull intact files, with no array to reconstruct. The hazard with single parity is a second drive failure while already in emulated mode: parity can emulate only one missing drive at a time, so a second loss in that state is unrecoverable.

One more Unraid trap: assigning a populated data drive into a parity slot tells Unraid to overwrite that drive's filesystem with parity data, which destroys the files on it. For a failed data drive, a stalled emulation, or a mistaken parity assignment, mail-in NAS recovery keeps the surviving XFS or Btrfs disks read-only while we extract, all at our Austin, TX lab.

TerraMaster TRAID: the arrays survive, the boot partition is what broke

TerraMaster RAID (TRAID) is not proprietary silicon. It is standard Linux mdadm layered with Btrfs or ext4, auto-expanding across mixed-capacity drives, and it is functionally the same abstraction as Synology SHR. That means a TRAID array reassembles on a vanilla Linux workstation with no TerraMaster hardware in the loop.

The state most owners land in comes from TerraMaster OS (TOS) firmware corruption or an interrupted firmware migration. The boot medium can no longer load TOS cleanly, and TOS then fails to recognize the existing arrays and prompts you to initialize the drives as new. The drives are fine. Accepting that initialize is the actual danger, because it writes a new empty array over intact mdadm members.

What distinguishes recovery here is that only the system and boot partition is corrupt while the mdadm data arrays are intact. We image every surviving member through a write-blocker with ddrescue or a PC-3000 first, then assemble the imaged members offline and read-only with mdadm and Data Extractor Express RAID Edition, repairing or ignoring the boot partition on the side. The boot partition is never repaired on the live drives.

If TOS is asking you to initialize a TRAID array you know held data, stop and mail the members to our Austin, TX lab before anything writes to them. No data, no recovery fee.

Buffalo TeraStation EM Mode: a boot fault, not a wiped XFS volume

Buffalo TeraStation and LinkStation data drives are XFS layered over Linux mdadm. When an interrupted write or firmware corruption hits the boot partition, the unit drops into EM Mode (Emergency Mode). NASNavigator may then report the drives as "Unformatted" or surface the EM Mode error directly, which reads to most owners like total data loss.

It usually is not. EM Mode blocks a normal boot, but by itself it does not corrupt the XFS data partitions. The skill that matters is telling EM Mode apart from an actual data-partition failure, because they look identical from the NASNavigator screen and call for opposite handling.

XFS metadata is sensitive to interrupted writes, so recovery works from images and does the delicate part offline: XFS journal replay and manual superblock correction run against the clones, never the originals. Every member gets imaged with ddrescue or a PC-3000 through a write-blocker before any journal replay or reboot is attempted, so a firmware retry cannot turn a boot fault into a data fault.

Facing an EM Mode banner or an "Unformatted" TeraStation, the low-risk move is to image before you reboot. Our lab handles Buffalo XFS recovery in-house with no fee if there is no data.

Asustor ADM: do not scrub a degraded Btrfs volume before it is imaged

Asustor Data Master (ADM) uses standard Linux mdadm with Btrfs or ext4, the same abstraction family as TerraMaster. On a single-drive failure, ADM marks the volume degraded and the array keeps running on reduced redundancy.

The trap on ADM is the scrub. On a degraded Btrfs RAID 1 or RAID 5 volume, a btrfs scrub must not be run before every surviving member is raw-imaged. A scrub reads and rewrites across already-marginal members, and that load can push a second member into failure before any image of it exists. Once the second member drops, the safe offline path narrows.

The correct order is to raw-image all surviving members through a write-blocker with ddrescue or a PC-3000, then work only from the clones. Btrfs tree reads, mdadm assembly, and extraction all happen against images, so the marginal originals are read exactly once.

If your ADM volume is degraded and you have not yet imaged the disks, ship the Asustor drives to our lab and we clone before we touch the array. No data, no recovery fee.

Reading ADM pool status, and the Repair versus Initialize fork

ADM Storage Manager is the surface that reports pool status, but the words on screen map onto plain mdadm and Btrfs state underneath. A pool that reports degraded is an mdadm array running one member short: it stays mounted and keeps serving files on reduced redundancy, and your data is still intact on the surviving members.

A pool that has dropped below its redundancy tolerance, a second member gone on RAID 5 or both mirror members gone on RAID 1, unmounts and stops serving, because mdadm can no longer assemble a complete stripe set. A pool showing a rebuild or a consistency check in progress is an mdadm resync or recovery running, and the safe move there is to leave it alone until it finishes rather than reboot or pull a drive mid-sync.

The dangerous fork is Repair versus Initialize. Repair re-imports the existing mdadm superblock and rebuilds onto a replacement member, which does not touch the surviving members' data. Initialize, or creating a new volume, overwrites every member superblock permanently.

That is the same destructive class as pulling the drives into a different NAS and choosing to migrate or create a new volume without a verified image first, and it mirrors the TerraMaster trap where a firmware fault makes the interface offer to initialize the disks as new. Repair is the recoverable-safe path when the array is genuinely just degraded. Initialize is the single click that turns a recoverable degraded pool into an overwrite.

Because ADM is standard Linux, you can read the truth of the array without touching the Asustor firmware at all. Over SSH, mdadm --detail /dev/mdX shows the array state, the member roles, and which member dropped, and the Btrfs or ext4 filesystem sits under the volume exactly as it would on any Linux box.

That is why recovery does not need Asustor hardware in the loop: the pool geometry and member state come straight from vanilla tooling, and the reconstruction runs from raw member images taken before any ADM re-import. For a failed or below-tolerance array, our Asustor ADM degraded-pool recovery works from those clones, never the originals.

WD My Cloud OS 5: mdadm and EXT4, and a sector-size rebuild trap

WD My Cloud is an embedded-Linux NAS running on mdadm with an EXT4 data volume. Single-bay units are one EXT4 partition. Multi-bay units such as the EX2 Ultra, EX4100, PR2100, and PR4100 mirror the small system and config partitions with mdadm RAID 1 and keep user data on a separate mdadm volume formatted EXT4.

One clarification saves people a wasted panic: the My Cloud NAS line does not use bridge-chip AES encryption. The JMicron and Symwave bridge-chip AES traps belong to WD's My Book and My Passport USB drives, not to My Cloud.

Pulling a My Cloud disk and reading it on Linux does not hand you ciphertext. Multi-bay units do offer optional dashboard software volume encryption, but that is separate, it is off unless you turned it on, and it needs the passphrase you set.

The array usually goes degraded after a failed drive replacement, and this is where the real hazard lives. Do not mdadm --add a mismatched-sector replacement, for example a 512e drive against a 4Kn array or the reverse. A sector-size and geometry mismatch corrupts the array rather than healing it. The safe path is to image the surviving members with a write-blocker first, then reconstruct the mdadm volume and mount EXT4 offline.

If a My Cloud rebuild dropped the volume or you are unsure whether a replacement drive matched, our lab images every member before any add or rebuild at our Austin, TX bench. No data, no recovery fee.

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 exhaust the drive's small CMR cache and trigger SMR band rewrites, which stall the drive for 30 to 90 seconds. That stall exceeds the controller command timeout of 8 to 20 seconds, so the controller 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.