There is one instruction on this page and everything else is explanation. If a disk has dropped out of your NAS, do not put a new one in and start a rebuild. Not yet.
A RAID 5 or RAID 6 NAS with one failed disk is degraded. Every byte of your data is still there and still readable — the missing disk's contents are reconstructed on the fly from parity, every time you read a file. It is running without a safety net, but it is running, and in that state it can be imaged cleanly and completely.
The moment you insert a replacement disk and start a rebuild, the controller has to read every sector of every remaining disk to calculate what goes on the new one. That is the heaviest sustained read load those disks have ever experienced in their lives.
And they are the same age as the one that just died. Bought on the same day, from the same batch, with the same power-on hours. Drives from a single batch fail at similar times — that is not superstition, it is manufacturing tolerance. So the rebuild is precisely the moment a second disk is most likely to give up.
When it does, you no longer have a degraded array. You have one that has been partially overwritten with parity calculated from incomplete data. Some of what was written is correct. Some is not. Nothing records which is which. That is why a failed rebuild is a forensic reconstruction and costs accordingly.
Not a reboot. Off. A NAS that has lost its volume will keep trying things, and some models will offer to re-initialise the array to "repair" it — which writes new metadata over the old.
Before you touch a single disk. You want a record of which drive was in which bay, and which lights were showing what.
Masking tape and a marker. Bay order is one of the parameters that has to be solved to reconstruct the array — and if you tell us, we do not have to work it out by brute force. This turns a two-week job into a three-day one.
Do not bin it. Do not RMA it. It is frequently the most valuable object in the box, because it holds the pre-failure state of the data that a rebuild has since overwritten everywhere else.
Honestly. Including anything anyone did at the weekend. It is not a confession, it is a map.
— "the volume is not active", or the volume simply vanishes from the storage page. Very often the underlying md-RAID is intact and it is the LVM or ext4 layer above it that has broken. QNAP's own repair tools can make this significantly worse, and the "recover volume" button is not a recovery tool in the sense you are hoping.
— SHR is not a standard RAID. It is a layered construction of md-RAID plus LVM designed to allow mixed disk sizes, and it cannot be treated as an ordinary array or read by a standard RAID controller.
— firmware corruption after a power cut during an update is common, as are BTRFS volume failures on newer units, which fail in their own particular way.
— "EMmode" or a flashing error light. XFS underneath, older hardware, and frequently a small business's entire history on it.
— usually a single drive. There is no redundancy and there never was, whatever the owner assumed.
It feels like one. It has redundancy, it sits in a cupboard making reassuring noises, and it is where everything important gets put. But redundancy protects you from exactly one thing: a disk failing.
It does not protect you from ransomware, which encrypts every share it can write to. It does not protect you from a power surge that takes the whole unit. It does not protect you from a firmware update that will not mount the volume afterwards. And it does not protect you from somebody deleting a folder, which deletes it everywhere, instantly, by design.
If your backup is a permanently mounted share on the same NAS, it is not a backup. It is a second copy of the problem.
Drop the drive at our Quayside reception, or post it to us — it costs nothing to find out what happened. You get a written figure from the fixed bands before any work begins.