Synology Volume Crashed? Do Not Rebuild It Yet

Direct answer: when a Synology reports a crashed volume, stop and do not click Repair. Power the NAS down, label every disk with its bay number, and get the array evaluated. A repair or rebuild forces a write across a degraded array, and if a second disk is marginal it can turn a recoverable volume into an unrecoverable one.

Crashed NAS diagnostic table

Why the Repair button is dangerous

A rebuild is one of the most demanding things you can ask an array to do. It reads every sector of every remaining disk, at sustained load, for hours or days.

Disks in a NAS are usually the same model, bought at the same time, and have run the same hours under the same conditions. When one fails, the others are statistically close behind. A rebuild is precisely the workload that finds the second weakest disk - and if it fails mid-rebuild, you now have a partially-rewritten array with redundancy gone.

This is the single most common way a recoverable NAS becomes an expensive one. The array as it sits right now, powered off, is in the best state it will ever be in.

Do this instead

1. Power the NAS down cleanly if it is still responsive, or pull power if it is not.
2. Label every disk with its bay number before removing anything. Write directly on the disk label. Array reconstruction depends on knowing the original order, and guessing wrong wastes hours.
3. Do not insert a replacement disk. Adding a disk can trigger an automatic rebuild on some configurations.
4. Do not re-seat disks to "reconnect" them. A disk that dropped out is usually failing, and re-seating it invites the controller to trust it again.
5. Note what happened just before the crash - a power cut, a firmware update, a disk warning ignored for weeks. It genuinely narrows the diagnosis.

If the volume is still mounted and merely degraded, that is different: copy your most important data off immediately, to something outside the NAS, before doing anything else. A degraded array that is still readable is a window that may close.

What recovery involves

Each disk is imaged individually, read-only, with hardware that can work around bad sectors. Nothing is written to the original disks at any point.

The array is then reconstructed virtually from those images - determining the RAID level, stripe size, disk order and parity rotation, which Synology stores in Linux md-raid metadata, usually with Btrfs or ext4 on top. Because this happens against copies, we can try several reconstructions without risk. That is exactly what a live rebuild cannot do.

Btrfs volumes add a wrinkle worth knowing: Synology's Btrfs implementation keeps checksums that can identify corrupted data precisely, which helps, but a crashed Btrfs volume can also refuse to mount over a relatively small metadata problem while the underlying data is entirely intact.

Most NAS recoveries run three to seven days, driven mainly by imaging time across multiple disks. Our evaluation is a flat $50, same day, and there is no recovery fee if no usable data is recovered.

Frequently asked questions

Should I click Repair on a crashed Synology volume?

Not before the array is evaluated. A repair forces a sustained read and write across every remaining disk, and if a second disk is marginal it can fail mid-rebuild and leave the volume unrecoverable.

Can data be recovered from a crashed Synology volume?

Frequently yes, including cases where two disks have dropped out. Each disk is imaged read-only and the array reconstructed virtually from those images, so multiple approaches can be tried without further risk.

Does RAID protect me from needing backups?

No. RAID protects against a single disk failing, not against controller faults, power events, ransomware, accidental deletion, or two disks failing together. It is availability, not backup.