What Happens During a NAS Crash

A NAS (Network Attached Storage) crash can involve failure at multiple layers: individual drives, the RAID array, the filesystem, or the NAS controller board itself. Consumer and small-business NAS devices from Synology, QNAP, Buffalo, TerraMaster, and Asustor run Linux-based operating systems (DSM, QTS, TerraMaster OS) with software RAID managed by mdadm or Btrfs. When a NAS becomes inaccessible, the specific failure mode determines what data is recoverable and how.

Three Categories of NAS Failure

Filesystem Corruption on Multi-Disk Arrays

Consumer NAS devices typically use ext4 or Btrfs as the filesystem on top of the RAID volume. Both filesystems use journaling (ext4) or copy-on-write (Btrfs) to maintain consistency during writes. However, these protections have limits.

Power loss during active writes can corrupt the filesystem if the NAS does not have a UPS and the drives do not have reliable power-loss data protection. Most consumer NAS devices do not have battery-backed cache. The drives' own write cache may report writes as complete before they are physically committed to the platters, creating a window where data can be lost.

Synology SHR (Synology Hybrid RAID) and QNAP's RAID configurations are built on Linux mdadm. The RAID superblock metadata (drive order, chunk size, parity layout, array UUID) is stored on each member drive. If the superblocks become inconsistent (due to a drive being temporarily disconnected and then reinserted after the array has changed), mdadm may refuse to assemble the array or may assemble it with incorrect parameters.

RAID Metadata Damage

NAS RAID metadata is stored in the mdadm superblock (version 1.0, 1.1, or 1.2, depending on NAS vendor and firmware version). This superblock records:

• Array UUID (unique identifier for the array)
• Member drive positions and UUIDs
• RAID level, chunk size, and layout algorithm
• Array state (clean, active, degraded, rebuilding)
• Event counter (incremented on every state change)
• Bitmap location (for write-intent bitmaps)

If drives are removed and reinserted in a different order, or if drives from different arrays are mixed, the superblock event counters may not match. mdadm uses the event counter to determine which drives have the most recent data. Mismatched counters can cause mdadm to exclude a drive it considers stale, even if that drive has valid data.

Some NAS firmware updates modify the RAID configuration or partition layout. If a firmware update is interrupted (power loss, network failure), the RAID metadata may be left in a transitional state that the NAS cannot resolve on its own.

Why Pulling Drives and Running Consumer Tools Makes It Worse

When a NAS fails, a common reaction is to pull the drives and connect them to a PC. This creates several problems:

1. Windows cannot read the filesystem. NAS volumes use ext4, Btrfs, or XFS. Windows does not natively mount these. Windows Disk Management may prompt to "initialize" the disk, which would overwrite the partition table and RAID metadata.
2. Linux may auto-mount or fsck. Connecting drives to a Linux system may trigger automatic filesystem checks (fsck). If fsck runs on a RAID member drive individually (outside the RAID context), it can modify the filesystem metadata in ways that corrupt the RAID volume.
3. Drive order is lost. The physical slot position of each drive in the NAS determines its role in the RAID array. If drives are removed without labeling their slot positions, reinserting them in the wrong order can cause the NAS to fail to assemble the array or to assemble it incorrectly.
4. Consumer recovery software scans individual drives. Tools like Recuva, Disk Drill, or PhotoRec scan a single drive at a time. They cannot assemble a RAID array. Running a scan on an individual RAID member drive will find fragments of files but cannot reconstruct complete files that span multiple stripes across multiple drives.

NAS Controller Board Failures

When the NAS hardware itself fails (CPU, RAM, power supply, internal flash module), the drives are typically unaffected. Because consumer NAS devices use software RAID (mdadm), all RAID metadata is stored on the data drives, not on the NAS controller. This means the drives can be read by any system running Linux with mdadm, provided the correct assembly parameters are used.

Recovery from a NAS controller failure involves:

1. Removing all drives and labeling their slot positions
2. Imaging each drive individually using a hardware imager or ddrescue
3. Scanning images for mdadm superblocks to determine array parameters
4. Assembling the RAID array from images (not original drives)
5. Mounting the filesystem read-only and copying data

Alternatively, installing the drives in an identical NAS model (same manufacturer, same model, same or newer firmware) and selecting "Migrate" instead of "Install" during setup may allow the new NAS to recognize the existing array. This is not guaranteed and depends on the NAS manufacturer's migration support.

Btrfs-Specific Failure Modes

Synology DSM 7+ defaults to Btrfs for its volumes. Btrfs provides checksumming and copy-on-write at the filesystem level (similar to ZFS). However, Btrfs RAID 5/6 has a known "write hole" issue that the Btrfs developers have documented: if power is lost during a write that spans a parity stripe, the parity may become inconsistent with the data. Synology mitigates this by using mdadm for RAID below Btrfs (SHR uses mdadm RAID + Btrfs filesystem on top), but QNAP and some custom NAS builds may use Btrfs-native RAID.

Btrfs maintains extensive internal metadata: the chunk tree, extent tree, device tree, and checksum tree. Corruption of the chunk tree (which maps logical addresses to physical device locations) can make the entire filesystem unmountable. Recovery from chunk tree corruption requires parsing raw Btrfs structures on the disk images to reconstruct the mapping.

Frequently Asked Questions