The lab is taking new cases · 9am–5:30pm, Mon–Fri In a hurry? Call 0800 6890668
SDR Southampton Data Recovery 0800 6890668 Open a case
SDR / Specialist / Synology data recovery

Specialist · Synology NAS work

“Volume Crashed” means DSM has stopped trying. Your files have not moved.

That one alarming line stands in for three unrelated faults — members dropping out of the RAID, LVM losing track of its map, or the btrfs tree going bad — which look the same on screen and want opposite handling. So the move that is right in every case is the dull one: switch the DiskStation off and stay away from Repair.

Most jobs: no data back, no charge Free diagnosis & quote in writing Postal intake across all of Hampshire

Speak to an engineer about it
0800 6890668

What those signs actually mean.

Not listed? Try the triage →
The problemWhat that tells youFirst step
DSM reports Volume CrashedOne alert covering three possible culprits: RAID, LVM or btrfsSwitch off and leave Repair alone
DSM reports Storage Pool DegradedA disk has dropped; the pool still runs, but with no protection leftEach further hour adds risk
The DiskStation enclosure has diedYour data sits on the disks, not in the chassisAmong the better outcomes
Rebuilding onto a replacement disk stalled, or 'crashed'The long read of a rebuild exposed another weak diskStop now; clones will tell
Disks put in a PC that now asks to format themNormal — Windows cannot read Linux NAS layoutsRefuse every prompt
A ransom demand sitting where your shares wereOne of the NAS-targeting families got inPhotograph it, shut down, read our ransomware page
Sending it in: send your device by tracked, fully insured post to our secure intake lab — return postage is free — or ring us first and we'll talk you through packing it. Postage details sit on the contact page.

SHR explained — and why one-size recovery tools find nothing.

Slices rather than whole disksEach disk is cut into slices matched to the smallest member, which lets drives of different sizes all pull their weight — neat provisioning that leaves one volume concealing several distinct arrays.
Standard components, odd arrangementNothing here is proprietary: mdadm arrays over the slice groups, pooled with LVM, then btrfs or ext4 on top. None of it needs Synology hardware to come back — only the layers taken apart in precisely the right order.
Why single-array tools find nothingFour mixed disks in SHR-1 can amount to three or four mdadm arrays beneath one LVM volume. Aim a tool that expects a single array at it and there's no layout there to find.
Two repairs never to attemptThe Repair control in DSM, which mid-crisis can drop healthy members and write over metadata — and btrfs's own repair command, which its documentation warns may finish off a tree that is already damaged. Here, both give way to read-only assembly from clones.

How the recovery runs, step by step.

Browse recent cases →
01

Logged in, checked at no cost Free

As soon as it lands with us, your device gets its own case number. An engineer works out the fault, says what can genuinely be pulled off, then puts one fixed price in writing — no charge for diagnosis, no obligation, and no chargeable work until you approve it.

No-cost diagnosisQuote fixed in writingNo commitment
02

Clone each disk, nothing written

Every disk is cloned with its bad sectors charted. The DiskStation never gets a chance to resume anything, and the earlier btrfs roots stay in the state the crash left them in.

Every member imagedEarlier roots kept intact
03

Take the layers apart in sequence

Working on the clones: the slices mapped, each mdadm array reassembled, the LVM map read, then the ext4 or btrfs volume mounted read-only — one layer at a time, in the sequence that works.

mdadm → LVM → volumeRead-only assembly
04

Pin down the layer at fault

A crash at btrfs, LVM or RAID level each gets its own fix, applied to the reconstruction — btrfs wound back to an older sound tree when the newest is broken — and the shares checked before sign-off.

Repair aimed at the layerShares checked on return
05

Checked, returned, signed off

You sign off a complete list of the recovered files first; only then does the recovery fee fall due. Everything returns on fresh media, postage paid, and the job stays open until you confirm the files open at your end.

Sign-off on the file listFresh media suppliedReturn postage on us

First checks on the bench

  • Three illnesses, one symptom — a broken btrfs tree, missing LVM metadata and a dropped mdadm member all surface as Volume Crashed. Working out which means reading the layers, not the banner.
  • btrfs carries its own rewind — because it writes copy-on-write, older tree roots frequently remain on the disk, and dropping back a single generation restores volumes the current tree had written off.
  • Repair has done real damage — pressed mid-crisis it can throw out good disks and overwrite the very metadata a reconstruction depends on. It suits a mostly-well pool, not a crashed one.
  • Ransomware is about exposure, not the brand — campaign after campaign against NAS boxes fits one profile: units answering from the open internet on old firmware. Keep it unreachable and patched and most of the defence is done.

The structural point that settles these jobs: an SHR volume built from unequal disks isn't a single array — it's a stack of mdadm arrays over per-disk slices, pooled by LVM under one filesystem. Unwind those layers out of sequence and you find nothing; unwind them properly and volumes the DiskStation called crashed come back routinely.

Out of the casebook.

EX · SDR-2026-0857CONFIRMED ✓

A four-bay DS of mismatched disks, brought down by its own helpfulness

A pair of 4TB disks, a pair of 8TB, one dead member, and an overnight DSM rebuild that finished in Volume Crashed. Beneath that sat three distinct mdadm arrays: two intact, the third degraded but still derivable. Reassembled in sequence off the box, with the btrfs tree wound back a single generation, every share came back.

All shares restored5 days on the bench

While it's still with you.

Do

  • Shut the box off the moment you see crashed or degraded
  • Note each disk's bay number before pulling it
  • Post the disks, or the whole box untouched
  • Tell us whether it was SHR or standard RAID, if you know

Avoid

  • Hit Repair on a degraded or crashed volume
  • Point a btrfs repair command at the original disks, ever
  • Let a PC initialise the disks
  • Shuffle bays to work out which disk went

Bench questions, straight answers.

Volume Crashed in DSM — have I lost the data?

Very unlikely. Crashed only says DSM can't put the stack back together — perhaps the RAID lost members, perhaps LVM metadata broke, perhaps the btrfs tree corrupted. Three separate faults, and mostly recoverable ones; the message simply can't say which. Leave it powered off and all three stay open.

Is SHR a closed format? Must I have a second Synology?

No. Underneath, SHR is ordinary Linux: mdadm software RAID over partition slices, pooled by LVM, then formatted as btrfs or ext4. From drive images it rebuilds on a normal workstation; the trouble only starts with tools or people expecting a single flat array.

Is it safe to let DSM rebuild onto the new disk?

Not until every member disk has been imaged. A rebuild pulls each sector off the tired survivors — precisely the strain that triggers a second failure — and it can write over the old filesystem roots that recovery leans on. Image them first and the rebuild carries no risk.

The NAS was hit by ransomware — any way back?

Often in part, sometimes in full, depending which strain hit — campaigns aimed at NAS boxes exposed to the internet go back years, so we check snapshots, replication targets and remnants in free space. Photograph the note, shut the unit down, and start with the routes on our ransomware page.

Whatever has gone wrong, keep it switched off.

Powering a damaged device up again costs you data. Start a case first; diagnosis is free whatever you decide.

0800 6890668