Linux-based software RAID underlies the thin pool created by LVM (Logical Volume Manager) above it, followed by the file system and finally the shares. Therefore, when there is a failure at one of these layers, it will be reported as “nonsense” several layers up, which is why the error you see rarely names the layer that actually failed.
QNAP uses an additional layer atop their RAID for the purpose of creating a “storage pool,” and often also includes “thin provisioning.” In this scenario, a volume may completely disappear and yet all of the individual disks beneath are healthy, thus the recovery process involves de-layering back down through the layers.
QNAP units use mdadm for software RAID similar to other NAS manufacturers, but most configurations have an added layer between the array and the file system. This added layer of LVM thin provisioning is what differentiates QNAP recoveries from Synology ones.
Thin provisioning means that when you need to allocate additional storage space in your NAS, it happens automatically without needing to preallocate (i.e., assign) the new storage space. Additionally, an association or mapping table identifies which logical volume each physical extent belongs to. If this table becomes damaged, although the physical drive(s) may be fine, the logical volume will remain unmountable since the operating system does not know how to properly identify the correct blocks for mounting the file system.
In essence, many QNAP jobs have two phases: first, you must assemble/restore the physical RAID configuration; second, restore the original association/table of thin provisioned areas so that the file system is accessible again.
TS-251D, TS-253D Two-bay consumer & small office models. The most commonly used QNAP model we see.
TS-453D, TS-464 Four-bay business models. Usually the primary filestore for the entire organisation, frequently with no off-site backup.
TS-h series These are all based on ZFS, which has a different underlying layout. Therefore, every vdev member needs to be available for reconstruction to begin.
TVS series Multi-bay model. More expensive version. With an SSD cache tier, there is one more level to rebuild.
TR expansion units JBOD (Just a Bunch of Disks) enclosures that are connected to a head unit. Send both units together, as the entire configuration travels with the head unit.
Rackmount TS-x83 and TS-x77 The business rack units from science park and estate server rooms.
QTS will offer to recover/rebuild/initialise a degraded volume. In each case the write operation occurs on the array. On a unit where the thin provisioning metadata has been corrupted, an initialise cannot be undone.
You should never insert/remove disks to “test” them. Removing/reinserting disks can create problems because bay position is stored in the array and removing/reinserting disks can cause a rebuild you did not intend. Turn off the unit, take photos of the front, mark each disk to show which bay number it has come from and send all members including any disks that are currently showing as failed.
A great deal of the time it is thin provisioning metadata damage rather than actual disk failure. There could be absolutely nothing wrong with the array. Under no circumstances allow QTS to perform a repair.
Most of the time the disks are recoverable. The second disk has often been ejected due to a timed out condition instead of a failure. You need to send all disks labelled with their respective bays.
In some cases, yes, but it can also trigger an initialisation process that would end things. It is just not worth taking the chance if you care about losing your data.
The disks remain readable without it. Since QNAP arrays are able to re-assemble on another set of hardware, it is rare that a dead chassis will result in lost volumes.
From £500 +VAT for multi-bay units. This cost is agreed in writing after our free 48-hour diagnostic.