A NAS is a small computer with disks attached, so “I cannot reach my files” covers four different problems and only one of them is a data problem. Underneath the vendor interface most units run ordinary Linux software RAID, which is why a unit whose electronics have died is very rarely a lost volume. What decides the outcome is what happens in the first hour: do not rebuild, do not reseat, do not initialise. Label the drive order and send the whole set.
$ cdr diagnose /dev/nas → NAS: Synology DS920+ · 4 × 4 TB · SHR → Status: VOLUME CRASHED — disk dropped, Btrfs damaged → Client: confidential · Cambridge CB2 $ cdr engineer-working → Member disks: all 4 imaged read-only → SHR + LVM: reassembled off the box → Btrfs: repaired · volume mounted $ cdr verify → ✓ shares — 11.2 TB → ✓ photos + backups — restored → ✓ NAS recovered — data back
Four instincts, all reasonable, all capable of turning a recoverable volume into a lost one.
A rebuild reads every sector of every remaining disk and writes across the replacement. On an array that has been quietly degraded for weeks, that sustained load is exactly what makes a second disk drop out mid-process.
Pulling disks to check them loses the order they were in, and the order is part of what makes the array readable. Label each bay before anything comes out.
Create volume, initialise, repair, factory reset — all of these write new metadata over the old. This is the single most destructive button on the interface and it is rarely labelled as such.
A degraded array left running is spending the margin protecting you. Shut it down properly, label the disks by bay, and take the whole set out of service.
Worth working through before assuming the worst, because three of these cost nothing to resolve.
The fact that makes most NAS recoveries possible, and the reason a dead box is rarely a lost volume.
Whatever the vendor interface looks like, nearly every consumer and small-business NAS runs ordinary Linux software RAID underneath — mdadm arrays, usually with LVM on top, and either ext4 or Btrfs above that. The disks are not written in a proprietary format that only that box can read.
This matters enormously in practice. If the unit's electronics have died, the disks can be read on other hardware entirely and the array reassembled from their superblocks. You do not need a working NAS of the same model, and you certainly do not need to send the disks back to the manufacturer.
What complicates it is the layers above. Synology Hybrid RAID adds partitioning across mismatched disk sizes. QNAP uses LVM thin provisioning, which introduces a mapping layer that has to be rebuilt before the file system is reachable. Both are well understood; they simply add steps.
A four-bay unit gets bought when a company is small, does exactly what is needed, and is never revisited. Three years later it holds the entire working file store, the accounts, the design history and the only copy of things nobody has thought about in a while. Nobody owns it, no one is watching the notification emails, and the first anyone knows of a failed disk is when a second one goes and the volume drops.
That is the sequence behind most NAS jobs from the Cambridge science parks and the Milton Keynes and Huntingdon business estates. It is recoverable — but only if the first hour goes the way described at the top of this page.
Send every disk, labelled by bay. Not just the one that failed. The array is reconstructed from the whole set, and a missing member on a RAID 5 with one disk already out means there is nothing to rebuild from.
Multi-bay NAS recovery starts at £500 +VAT, whatever badge is on the front and however many bays are involved. Single-bay units are priced as ordinary single-drive work from £300 +VAT.
The figure is fixed in writing after the free 48-hour diagnostic. Where individual disks need clean-air work on top of the array reconstruction, that is identified and quoted at the same point rather than added later.
Not if the data matters more than the convenience. A rebuild puts every remaining disk under sustained full-surface load, and on an array that has been degraded a while that is precisely when a second disk goes. Copy the data off first, then rebuild.
Almost always. Synology, QNAP and most others use standard Linux mdadm arrays, so the disks can be read on other hardware and the array reassembled. You do not need a replacement unit of the same model.
Yes, and labelled by bay if you possibly can. The array is reconstructed from the full set and the order is part of the structure. Send the unit too if that is easier than pulling them.
Frequently a thin-provisioning metadata problem rather than disk failure. The mapping layer between the logical volume and the physical blocks has been damaged. Recoverable, but do not let the unit attempt a repair first.
No, and this is the misunderstanding behind most jobs we see. RAID protects against a disk failing. It does not protect against deletion, ransomware, fire, theft or the controller writing garbage across every member at once.
Typically five to ten working days. Every disk is imaged individually before any reconstruction is attempted, and on a four-bay unit of large disks the imaging alone accounts for much of that.
From £500 +VAT after a free diagnostic, whatever the badge on the front. Send every disk, labelled by bay if you can — and do not let it start a second rebuild or a scheduled scrub while you decide.