A member dropped, nobody noticed
The array runs degraded until a second disk follows. The commonest arrival by a wide margin, and entirely preventable with alerting that someone reads.
Most common
Linux software RAID underneath, an LVM thin pool above it, then the file system, then the shares. A fault at any level surfaces as nonsense several levels up, which is why the error you see rarely names the layer that actually failed.
QNAP stacks a storage pool, and often thin provisioning, on top of the RAID. A volume can disappear entirely while every disk underneath is in good health, so recovery means unwinding those layers in order.
Worth knowing because it explains almost every QNAP failure mode.
Standard Linux software RAID assembling your disks into an array. This is conventional and well understood, which is why QNAP recovery is generally more tractable than a proprietary hardware controller.
The array is presented as a physical volume and carved into logical volumes. On most QNAP configurations this is a thin pool, which is where the complications begin.
Sitting on a logical volume. Conventional, with its own backup superblocks that a recovery can rebuild from.
What you actually see over the network. A fault here looks identical to a storage failure from a client machine, which is why pinging the unit and checking the admin interface matters before assuming the worst.
The single biggest difference between QNAP recovery and a plain array.
A thin-provisioned volume reports a size it has not actually reserved. You create a 10TB volume on a 6TB pool, and space is allocated only as data is written. It is efficient and it is also the source of a failure mode that surprises people.
If the underlying pool fills, writes fail while the volume still reports free space — because the volume was never backed by the storage it advertised. The file system, believing it has room, can be left with structures half-written. QNAP units do warn about pool utilisation, and those warnings are routinely dismissed as capacity planning rather than a stability risk.
For recovery it means the mapping metadata matters as much as the data. A thin pool records which physical extents back which logical addresses, and without walking that mapping correctly the volume reconstructs as noise even when every disk is perfectly readable.
The array runs degraded until a second disk follows. The commonest arrival by a wide margin, and entirely preventable with alerting that someone reads.
Thin volumes overcommitted, the pool fills, writes fail mid-operation and the file system is left inconsistent while reporting free space.
The unit reboots into a state where it cannot mount its own volumes. The disks are usually untouched — the appliance is the problem.
ext4 structures damaged mid-write. Conventional logical damage, rebuilt from the file system’s own backup superblocks.
The appliance is removed from the equation entirely.
Every disk is imaged read-only first, including any the unit has ejected. The mdadm array is then assembled from the images with the geometry derived from the data rather than trusted from the unit that failed to assemble it — stripe size, member order and parity rotation each tested until structures resolve coherently.
The LVM metadata is then read to establish the pool layout and, on a thin pool, the mapping from logical addresses to physical extents is walked to locate where the real data sits. Only then does the ext4 volume appear, and it is repaired from its own backup superblocks where necessary.
Because every layer is standard Linux storage, none of this depends on QNAP firmware or on the unit powering on at all. NAS and RAID recovery in Manchester is from £500 +VAT after a free 48-hour diagnostic. Send the disks labelled by bay, or the whole unit — both work.
Less than people expect. Underneath the interface it is standard Linux storage — mdadm, LVM and ext4 — so once the disks are imaged the reconstruction is conventional and the appliance becomes irrelevant.
A thin volume reports a size it has not actually reserved, allocating space only as data is written. If the underlying pool fills, writes fail while the volume still shows free space — and the file system can be left with structures half-written.
Usually not. That is normally ext4 damage from an interrupted write, which is conventional logical damage rebuilt from the file system’s own backup superblocks. The disks themselves are typically fine.
Yes. Because every layer is standard Linux storage, the array can be assembled and the volume mounted entirely outside the appliance. A dead QNAP with healthy disks is one of the better outcomes.
Copy your data off first. A rebuild reads every sector of every surviving member for hours — the heaviest load the array ever sees, applied to disks the same age as the one that just failed.
From £500 plus VAT after a free 48-hour diagnostic, with a 50% deposit where a member needs physical drive-level work. Send the disks labelled by bay or the complete unit.