Synology Storage Pool Degraded or Volume Crashed: What to Do First

Storage Manager has turned orange or red, and the word on the screen is either Degraded or Crashed. They look alike and mean opposite things. One is a routine repair DSM does for you. The other is the one situation on a NAS where a single wrong click or pasted command removes your data for good.

This page is deliberately slow at the start. The fast part — what to click, what to type — comes after you know which of the two cases you are in.

What you see on the screen

Not sure which you have? Open Storage Manager → Storage Pool and read the status word exactly. Do nothing else there yet.

🛑 Read this before you touch anything

Each of these turns a recoverable situation into an unrecoverable one. Each comes from a real case.

1. If the status is Crashed and your shared folders still open — do not shut down, do not reboot. This is Synology's own instruction: while the data is readable, the only correct move is to copy it off the NAS now. A reboot may be the last time the array ever assembles.
2. Do not click Remove, Delete or Create on any pool or volume — not "to start fresh", not "to see if it helps". Removing the pool wipes the RAID metadata every later recovery depends on.
3. Do not paste commands you do not understand. The classic mistake is one word: mdadm --create instead of mdadm --assemble. The first builds a new, empty array over your disks and destroys the old one in a second. The second only tries to start the array that is already there. In a terminal they look almost identical.
4. Do not pull drives out to "reseat" them. The one exception is a drive that was just removed by accident — put it back in the same slot and nothing else (Branch B3).
5. Do not start Repair until you know which drive failed and have a healthy replacement in your hand.
6. Do not write anything to the volume — no new files, no third-party "disk check", no package updates.

If you have already done one of these, write down exactly what and in which order. Whoever helps you next will need it.

Degraded or Crashed: the one distinction that matters

Synology's documentation is precise:

A storage pool becomes Degraded when one or more of its drives becomes defective, but the storage pool remains accessible because no data loss has occurred. You can use the Repair feature to repair a degraded storage pool and return it to a healthy status. Before initiating the repair, replace the defective drives with healthy ones.

When the status of a storage pool becomes Crashed, you can no longer repair it by yourself.

Degraded is an array running without its safety margin. The data is there; one more failure and it will not be. The job is urgent but ordinary: replace the drive, run Repair.

Crashed means the array, or the file system on it, has already lost more than it could absorb. The job is no longer to repair but to get the data out — and if the data is not readable, to stop.

How many failures your array survives

Check the RAID type in Storage Manager → Storage Pool.

Two common misreadings. SHR with two drives is a mirror and survives one failure — Synology lists "SHR comprising of at least two drives" among the repairable types. Basic, JBOD and RAID 0 have no protection: Repair does not exist for them, and a failed drive means restoring from a backup.

Safe diagnosis: what is actually broken

Everything in this section only reads. Nothing here changes a byte on your drives.

In DSM

Storage Manager → HDD/SSD lists every drive with its health; the failed one is usually marked with its slot number. Storage Manager → Storage Pool shows the pool status and the progress of any Repair already running.

Write down: slot, drive model, status word, and whether DSM calls the drive missing, failed or critical. You will need this in every later step.

In the terminal (read-only)

The terminal shows more than DSM does, and costs nothing — as long as you stay with the three commands below. Each reads and reports. None writes.

Enable SSH in Control Panel → Terminal & SNMP, connect with an administrator account, and switch to root:

sudo -i

Synology documents the procedure: How can I sign in to DSM with root privilege via SSH?.

🟢 Safe — read-only. State of every RAID array the kernel knows about.

cat /proc/mdstat

Each line starting with md is one array. active means it is assembled and running. The bracket such as [UU_] has one position per drive: U is a working member, _ a missing one. A drive marked (F) was thrown out as faulty. A recovery or resync line with a percentage means a repair is in progress — leave it alone. An array not listed as active while its drives are physically present is the Crashed picture: the kernel could not assemble them.

🟢 Safe — read-only. Reads the RAID metadata ("superblock") from one drive and prints it.

mdadm --examine /dev/sdX

Replace sdX with the drive name (sda, sdb, …) and run it for each drive in the pool. Compare across drives: Array UUID (must be identical on every member), Events (a counter — a drive far behind the others has been out of the array for a while and holds stale data), and State / Device Role. This is how you tell "one drive dropped out, the rest agree" from "the drives disagree about what the array is".

🟢 Safe — read-only. The drive's own health report (SMART).

smartctl -a -d sat /dev/sata1

On DSM 7 the drives are usually /dev/sata1, /dev/sata2, … (older DSM: /dev/sda, /dev/sdb); cat /proc/mdstat shows the names in use, and the same names go into mdadm --examine. The -d sat flag is what makes SMART readable through the SATA controller on DSM — the form used in this German thread and this archive thread.

A drive reporting reallocated or pending sectors, read errors, or timing out when queried is physically failing. Every further read from it may be the last — the strongest argument for a block-level copy before anything else.

What the results tell you

• mdstat: array active with one _; DSM says Degraded → one drive out, the rest consistent. Branch A. Good news.
• mdstat: array not running; --examine: same Array UUID everywhere, Event counts close → the drives are probably fine and the array simply failed to assemble. Data very likely intact, but getting it back is advanced work. Branch B — and read "When to stop".
• --examine: one drive far behind in Events → it left the array long ago. Forcing it back in corrupts live data with stale data. Professional.
• SMART: a drive physically failing, or more drives out than your RAID type tolerates → stop. Branch B2.

Decision tree

Status word in Storage Manager?
│
├── Degraded ─────────────────────────────► Branch A: replace the drive, Repair
│
└── Crashed
    ├── A drive was just pulled by accident ► Branch B3: put it back, same slot
    ├── Shared folders still open ─────────► Branch B1: DO NOT POWER OFF — copy now
    ├── Data not readable ─────────────────► Branch B2: stop; data-recovery lab
    └── NAS does not boot ─────────────────► Branch B4

Branch A — Degraded: replace the drive and Repair

Your data is intact. The array runs without protection — that is why this is urgent, not why it is dangerous. The only way to make it dangerous is to rush.

1. Identify the failed drive in Storage Manager → HDD/SSD and note the slot. If you cannot tell which drive failed, do not guess: pulling a healthy drive from a degraded RAID 5 or SHR-1 crashes it instantly. Stop and ask for help with your mdstat output.

2. Get a healthy replacement. Synology: "Before initiating the repair, replace the defective drives with healthy ones." Do not reuse the failed drive "to see if it was a glitch".

3. Replace the drive. Put the new drive into the slot the failed one came out of.

4. Run Repair. 🟡 Caution — changes state. Writes the rebuilt data onto the new drive, reading from the existing members. This is the action Synology prescribes.

Storage Manager → Storage Pool → select the pool → Repair.

5. Wait and leave it alone. On multi-terabyte drives a repair takes many hours, sometimes days — Synology has an article titled Why does it take a long time to repair a storage pool? for exactly this. Until it finishes: no reboot, no pulling drives, no heavy load, no second Repair.

If a second drive fails during the repair, the pool goes from Degraded to Crashed. You are in Branch B. Do not power off.

Basic, JBOD, RAID 0: no Repair option exists, because there is no redundancy. The path is your backup. Without one, Branch B2 — the drive may be partially readable by a professional.

Branch B — Crashed

Synology's article on crashed volumes describes four situations with an action for each. They are the four branches below.

B1 — Crashed, but the data is still readable

This is the one lost in panic. Synology's instruction: do not turn the system off. Copy your data to a computer or external drive immediately — irreplaceable things first (photographs, documents), media library last.

Only after the copy is complete and verified (open a sample of copied files, compare sizes) does Synology's procedure continue: remove the storage pool, run a memory test, create the pool again, restore from the copy.

Before the next step, make a block-level copy of every drive in the pool. Removing the pool is irreversible, and the copy you just made over the network is the only other thing between you and total loss. If you have no way to image the drives — no spare drives of equal size, no second machine — stop here and keep the NAS running until you do.

Storage Manager → Storage Pool → Remove. 🔴 Irreversible. Destroys the RAID metadata and everything on the pool.

Then run a memory test — Synology lists it because a crashed volume on healthy drives is sometimes bad RAM corrupting writes. (Memory Test in Synology Assistant — how to run it) Then create the pool anew and restore from your copy.

B2 — Crashed, and the data is not readable

Synology's position is one sentence: contact a data-recovery company.

We say the same, with one honest addition. An advanced route exists — our forum archive holds many threads where the array was brought back by hand, and several where the attempt finished it off. The commands and their exact order for Synology's disk layout are the subject of their own guide, after every one of them has been reviewed; they are deliberately not on this page, and they are not something to take from a random blog.

If you intend to try anyway, the rule is absolute: first a block-level copy of every drive, and every experiment on the copies, never on the originals. If you cannot make the copies, you have reached the end of what you can do yourself.

B3 — A drive was pulled out by accident

Put it back in the same slot, with the NAS running if it was running. Nothing else. DSM should pick it up; depending on how long it was out, the pool may show Degraded and offer Repair — that is Branch A. Synology has an article for this case: How do I repair a storage pool if a drive was accidentally removed.

Do not pull it out again, and do not try another slot.

B4 — The NAS does not boot

Synology's prescription: address the drive failure, then retrieve the data from the drives. In practice a drive has failed badly enough to stop the system, or the system partition DSM keeps on every drive is damaged. Both have separate guides — reading Synology drives on an ordinary PC, and recovering a crashed system partition. Do not reinstall DSM through Synology Assistant "to get in": that writes to every drive.

When to stop and go to a professional

This is not a disclaimer. Each line is a point where one more attempt by a non-specialist has, in real cases, turned recoverable into lost.

• A drive clicks, grinds or spins up repeatedly. Mechanical fault. Every power-on can destroy the platters. Power down and do not run it again.
• More drives are out than your RAID type tolerates. Rebuilding needs the stale drive's data merged by someone who knows exactly what they are doing.
• Crashed and the data is not readable. Synology itself says: data-recovery company.
• You cannot make a block-level copy of the drives. Nothing from the advanced route belongs on original drives.
• You are not certain which drive failed. Guessing in a single-parity array is a coin toss with your data.
• mdadm --examine shows one drive far behind in Events. Forcing it in overwrites good data with old.
• You already ran a write command — --create, a file-system repair, a pool removal — and are not sure what it did. Stop. What remains may still be recoverable with the right tools, but not after another attempt.

A data-recovery lab is expensive. It is still cheaper than the second attempt.

How not to be here again

• RAID is not a backup. It covers one drive dying — not a second one, a file-system fault, bad RAM or a wrong click. Keep what matters off the NAS as well.
• Replace a drive at the first warning. "Degraded" is DSM telling you the margin is gone.
• With four drives or more, consider SHR-2 or RAID 6. The second parity drive turns "a second failure during a 30-hour rebuild" from a disaster into an inconvenience.
• Turn on DSM notifications so a degraded pool reaches you within the hour, not the next time you open the web interface.

Sources

Official Synology documentation:

• Repair a Storage Pool — the Degraded / Crashed definitions and the list of repairable RAID types.
• What can I do if one of my volumes crashed? — the four crashed-volume situations in Branch B.
• Why does it take a long time to repair a storage pool?
• How do I repair a storage pool if a drive was accidentally removed
• Choose a RAID Type and What is Synology Hybrid RAID (SHR)? — the fault-tolerance figures in the table.
• How can I sign in to DSM with root privilege via SSH? — shell access for the read-only checks.
• How can I run a memory test on my Synology NAS? — the memory test in Branch B1.

Community cases this guide draws on (this site's forum archive and the German Synology forum):

• FAQ: Что делать если «отвалился» RAID массив
• Восстановление RAID5 после аварии
• [how-to] Defektes Raid-5 wiederherstellen
• DS723+: Volume abgestürzt. Wie vorgehen? Datenrettung möglich?

This guide was reviewed by a human before publication (the site's owner, who ran the forum this archive comes from for sixteen years). Last reviewed: 2026-10-09.