A QNAP that has dropped its volume is rarely a lost cause — the disks are usually fine and the storage pool metadata is not. The work is to read every member and rebuild the volume away from the unit.
QNAP layers a storage pool and often thin provisioning on top of the RAID, so a volume can vanish while every disk is fine. Recovery means reconstructing those layers in order, from read-only images.
A QNAP volume is not a single thing. Underneath sits a Linux software RAID set, usually mdadm; above that a storage pool, generally LVM; and above that the volume itself, often thin-provisioned so it can grow. A fault at any layer makes the volume disappear while the disks below stay perfectly healthy — which is why so many QNAP jobs arrive with every drive passing its SMART checks and nothing mounting. Recovery works upward through those layers in order rather than treating the array as one block.
The commonest cases are a RAID 5 that lost a second member during a rebuild; a pool marked degraded or inactive after a power cut interrupted a write; a thin volume that filled its pool and stopped accepting writes; and firmware updates that leave the array assembled but the pool unmountable. Snapshots complicate things usefully — a deleted file often still exists in a snapshot even when the live volume has moved on, provided the pool itself can be read.
Every disk is removed, labelled by bay and imaged read-only, with weak areas retried in short passes rather than hammered. The mdadm set is then reassembled from the images by deriving its parameters directly — chunk size, member order, parity layout and data offset — rather than trusting superblocks that may be stale. The LVM pool is mapped on top of that, thin-provisioning metadata is walked to locate the real extents, and the file system is rebuilt from what results. The QNAP itself is never asked to assemble, repair or rebuild anything.
Either the whole NAS or the disks alone is fine, but bay order is what matters — label each disk with the bay it came from before you pull it. Don’t reinsert a disk the unit has ejected, don’t let a rebuild or resync run, and don’t use the QNAP’s own repair tools first. If you already know which disk failed, say so; it saves diagnostic time. NAS work starts from £500 +VAT after a free 48-hour diagnostic.
Usually yes, and often the disks are entirely healthy. A QNAP stacks a storage pool and frequently thin provisioning on top of the RAID, so a fault in either upper layer makes the volume vanish while the drives beneath are fine. The layers are reconstructed in order from read-only images of every member.
Every disk is imaged read-only, then the underlying mdadm set is reassembled by deriving chunk size, disk order, parity layout and data offset from the data itself rather than relying on superblocks that may be out of date. The LVM pool and thin volume are mapped on top, and the file system rebuilt from there — all outside the unit.
Often, yes. A snapshot keeps the earlier state of the blocks a file occupied, so a file deleted from the live volume frequently still exists in a snapshot — provided the pool holding those snapshots can still be read and hasn’t been overwritten since. Stop writing to the NAS as soon as you notice.
Either is fine. If you send the drives alone, label each with its bay number first — bay order matters for reconstruction. Don’t reinsert an ejected disk and don’t let the unit run a rebuild or a pool repair before it comes in.
NAS, RAID and server recovery starts from £500 plus VAT, fixed in a written quote after a free 48-hour diagnostic. Where a member needs physical drive-level work we take a 50% deposit, with the balance payable only on a successful recovery.