Specialist work · Synology & QNAP
Volume Crashed, Inaccessible, degraded: DSM and QTS give you a status and leave you to guess which layer beneath it broke. The boxes reach us from across Birmingham and the West Midlands. It could be the mdadm set, the LVM pool above it, the btrfs or ext4 filesystem on top, or a disk that quietly left the array weeks ago. Each of those needs a different answer, and the wrong answer destroys the thing you are trying to get back. Keep it switched off until every disk has been imaged, and turn down anything offering to repair or reinitialise.
Tell an engineer what it is doing
0800 6890668
| What you see | What is behind it | What to do |
|---|---|---|
| DSM is showing Volume Crashed | One message, three candidates: the mdadm set, the pool, the filesystem | Shut it down and copy the message out |
| The dashboard reports a degraded pool | A disk has left the set; the rest are running with nothing in reserve | Every hour from here costs you |
| The QNAP shows no lights and no beep | The box stores nothing itself; your shares sit on the disks in the bays | This is often the good news |
| An update went in and the unit never returned | The system partition broke; the storage pool did not | Decline the offer to reinstall |
| Windows wants to initialise the disks | Expected: Windows reads neither btrfs nor ZFS | Turn it down |
| Shares emptied, a ransom note left in place | A campaign sweeping the internet for exposed NAS boxes | Take a photo of the note, cut the power, read the ransomware page |
Every item gets a case number of its own the day it lands. An engineer then works out what has actually failed and tells you plainly which files have a real chance of coming back and which do not. Only then does a price follow: one figure, fixed, in writing, and it costs you nothing to see it. Nothing is charged until you say yes.
Nothing is examined until there is a full copy of every disk sitting on our own storage. The unit itself stays off the whole time, so no scheduled repair or rebuild can start on its own and your disks are never written to.
The rest of the job happens on the copies. The mdadm superblocks are read for member order and chunk size, the LVM or thin-provisioned pool is mapped above that, and the btrfs, ext4 or ZFS volume is brought up read-only on our own hardware.
Whatever needs fixing — the array, the pool metadata, the filesystem — is put right on the assembled copy, never on the disks you sent. A broken btrfs tree or ext4 journal gets sorted out there, and each share is then opened and read.
No invoice is raised until the full list of recovered files has sat in front of you and you have said go ahead. Your data comes back on media we buy new, posted at our expense, and the job is not closed here until every file has opened on your own machine.
The detail that settles most of these jobs: a Synology volume is three layers deep — mdadm, then LVM, then btrfs or ext4 — and QNAP puts thin provisioning over the same idea. Member order, chunk size, start offset and the mapping above them all have to come off the images before one file is visible. Get it wrong and the disks look empty; get it right and a unit DSM had written off hands back everything.
The screen said Volume Crashed, and the DiskStation had spent the night rebuilding onto a disk that was already shedding sectors. SHR had spread four mismatched disks across more than one mdadm set, with LVM and btrfs stacked above, so no single disk meant anything on its own. All four were imaged, the layers put back in order, and every share opened.
Usually not. Volume Crashed is DSM saying it cannot bring the volume back online; it is a status, not a verdict on your files. The disks get read on our own hardware, well away from the box, so what the web interface tells you settles very little. Switch it off and your options stay open.
Not on its own, no. Synology stacks mdadm underneath LVM underneath btrfs or ext4, and QNAP lays thin provisioning over its pools, so one disk out of a bay is a fragment of something larger. Everything is done on images: member order and chunk size get worked out there, and the volume then comes up read-only on our own kit.
Almost never. The operating system sits on a small partition mirrored across every disk, well apart from where your shares live, so a failed update usually breaks the boot and leaves the pool alone. The real danger comes next, when the unit offers to reinstall and reformat the volume in the same breath and a tired owner agrees to it.
No. Snapshots live in the same pool as the files they are protecting, so a second disk failing mid-rebuild, ransomware or a dropped enclosure takes both together. Redundancy is not a copy. Most of the units we open held the only version of something. If it helps, a NAS can go to the Manchester lab whole, disks still in the bays.
Every extra power-up takes something off a drive that is already going. Leave it switched off and let the free diagnosis say what still reads.