Recovery methodsTechnical

Reconstructing NAS Storage Stacks

A NAS volume that won’t mount is rarely one problem — it’s usually several independent mappings stacked on top of each other, and repairing the wrong one first can erase what a lower layer still knows.

Start below the file system

A useful diagnostic model treats a NAS as a stack of layers: physical media, member identity and controller metadata, RAID or mirror geometry, pooling or LVM, thin/sparse/snapshot allocation, the host-visible volume, and finally the file system and application data on top. See Understanding Storage Layers Before Recovery for the general version of this stack. The question that actually matters is: at which layer did logical addressing stop being trustworthy? A hardware controller losing its virtual-disk configuration is a failure at the geometry layer. A Synology array that assembles fine but whose LVM is damaged is a failure one layer up. A QNAP thin pool with damaged allocation metadata is a failure at the allocation layer. In every case, a higher-layer repair should never be trusted until the lower layer feeding it has been validated.

Synology SHR is often several RAID arrays joined by LVM

Synology’s own documentation describes SHR as potentially consisting of multiple Linux MD RAID arrays integrated into one storage pool through LVM. A mixed-capacity example: two 4 TB drives and two 6 TB drives contribute a common 4 TB slice from every disk to one RAID 5 array, while the extra 2 TB on the larger pair forms a second, smaller RAID 1 array — both arrays then join through LVM into one logical volume carrying Btrfs or ext4. The exact segmentation varies by disk mix, but the recovery principle holds: identify every member partition, identify every required md array, reconstruct those arrays individually, reconstruct or activate LVM on top of them, then interpret the file system. SHR is not simply a strange RAID 5.

Synology’s own PC-based recovery procedure installs mdadm and lvm2, assembles the MD arrays and activates LVM outside the enclosure entirely — useful evidence that the physical NAS unit is not always required when the storage stack is internally consistent. That is a different situation from forensic reconstruction after stale members, an interrupted rebuild, or conflicting metadata, where the vendor’s own reassembly path may not apply.

System RAID and data RAID can share the same disks

Synology-style disks commonly carry more than one RAID signature — a small system array alongside the data array, plus swap or cache-related partitions. Do not reconstruct the first valid MD set found on a disk and assume it is the user-data array; identify the purpose of every RAID signature present before choosing which one to rebuild.

Btrfs and ZFS can validate the layers beneath them — or refuse to

Btrfs adds copy-on-write metadata, checksums for both metadata and data, generation numbers, multiple tree roots and snapshot/subvolume structures. This cuts both ways for recovery: Btrfs’s own checksum and tree-consistency checks can help confirm whether a reconstructed RAID/LVM layer is actually correct, and its copy-on-write design means damage to the newest root does not automatically destroy every historical tree. But Btrfs repair cannot repair a false block device produced by a wrongly reconstructed RAID or LVM layer underneath it — it can only tell you that layer is wrong.

QNAP’s QuTS hero is ZFS-based and should never be treated as a QTS variant. OpenZFS contributes a genuinely different model: pooled storage across VDEVs, end-to-end checksums, datasets, snapshots and clones built on copy-on-write, and transaction groups rather than in-place updates. ZFS snapshots are read-only views that initially share blocks with the active dataset, so a deleted or changed file may still be referenced by a snapshot, and destroying snapshot metadata can make those retained blocks reclaimable. QuTS hero recovery is ZFS pool and dataset recovery, not generic mdadm/ext4 QNAP recovery.

Static, thick and thin QNAP volumes are different recovery stacks

QNAP’s Flexible Volume Architecture separates a static volume (members directly forming the file system, parented by one RAID group), a thick volume (parented by a storage pool, with fixed allocation), and a thin volume (space allocated on demand from the pool, with over-allocation explicitly permitted). The distinction matters because a thin volume adds a genuine layer of state: the logical-to-physical allocation map is part of the data, and a raw scan of pool sectors cannot by itself reconstruct the original block order of a thin volume.

A storage pool can contain more than one RAID group

QNAP documents that one storage pool can aggregate several separate RAID groups. Recovery can therefore find multiple perfectly valid RAID groups and still be only halfway finished — the remaining question is how those groups were combined into the pool. Do not concatenate discovered RAID groups by capacity or apparent creation order without reconstructing the actual pool metadata that describes how they were joined.

Classify every flash device before deciding what to do with it

An SSD inside a NAS can be serving as read cache, write cache, a metadata device or tier, a full storage-pool member, a ZFS log/cache/special-vdev role, or a tiering participant. These are not interchangeable, and blanket advice like “just remove the SSD cache” can discard something the pool actually depends on. Classify each flash device’s role before treating it as disposable or as authoritative.

Practical rule

If the file system above a NAS stack is not receiving the same logical block addresses it received before the failure, repairing that file system is premature — the layer beneath it still needs proving.