Failure triage and data preservation
A Synology volume marked Crashed is a different event from a merely degraded storage pool. Synology states that a crash caused by drive or file-system errors cannot be repaired through the normal volume-repair workflow. The first question is therefore not which button repairs the array, but whether the system powers on and whether File Station can still read important folders. That distinction determines whether you should copy data immediately, investigate hardware, or stop before further changes reduce recovery options.
Quick answer
Treat readable data as the priority, not the status icon
If the NAS starts and the crashed volume remains readable, copy irreplaceable data to another system before deleting, recreating, scrubbing or experimenting. If the data cannot be read, repeated repair attempts can make the situation harder to diagnose. A crashed volume is not the time to assume SHR or RAID redundancy still guarantees recovery.
Current Amazon listings
Replacement and migration DiskStation options
Product cards are supporting purchase references only; they do not determine whether your failed drives are recoverable or whether a specific migration pairing is supported.
Technical decision
A crashed volume is a recovery problem first and a rebuild problem second
The safest path branches on power, readability and the cause of the crash. Readable data favors immediate evacuation. Unreadable data favors conservative handling and support or professional recovery. Accidental drive removal has a separate online-assemble path in DSM 7, but a genuine filesystem or drive-error crash should not be treated as an ordinary degraded pool.
Interactive recovery tool
Synology Failure Triage Tool
This tool routes the symptoms you select to a safer next step. It does not issue destructive commands. Before initializing a disk, deleting a pool, reinstalling DSM or moving the only copy of important data, verify the exact live Synology procedure for your model and DSM build.
Recovery safety checklist
Four rules before you change a failing Synology system
Preserve readable data first
If unique files can still be opened, copy or back them up before changing storage metadata, reinstalling DSM or running stressful diagnostics.
Record drives and bays
Capture drive serial numbers, bay positions, health states and DSM messages before swapping disks or moving them to another chassis.
Match the action to the failure layer
A degraded pool, crashed volume, failed system partition, bad drive and failed bay have different supported recovery paths.
Keep a rollback path
During migration or recovery, do not erase the source system until the destination data, permissions, applications and backups have been verified.
Crashed is not the same as degraded
A degraded pool can still expose a Repair action because redundancy has been reduced but the storage structure remains repairable. Synology describes a crashed volume from drive or file-system errors as not repairable in place, so this status changes the goal from restoring redundancy to protecting recoverable data.
For a crashed-volume incident, crashed is not the same as degraded changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Start with power and data readability
Check whether the NAS powers on, whether DSM accepts a login and whether File Station can browse important folders. These three observations divide the situation into very different risk levels and prevent an owner from applying a generic RAID repair sequence to a system that may already have filesystem damage.
For a crashed-volume incident, start with power and data readability changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
If files are readable, copy before changing storage
A readable crashed volume can still contain valuable intact data. Prioritize unique documents, photos, project files and configuration exports to another computer or storage target on the local network. Do not wait for a perfect full-volume copy before rescuing the most valuable small datasets.
For a crashed-volume incident, if files are readable, copy before changing storage changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
If files are unreadable, stop escalating writes
When DSM is reachable but files cannot be read, avoid initializing drives, creating replacement pools on the same disks or running random filesystem commands. Synology recommends professional data rescue for this scenario because additional writes can remove evidence or metadata that recovery specialists need.
For a crashed-volume incident, if files are unreadable, stop escalating writes changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Accidental drive removal has a special path
If the crash followed an accidental drive pull rather than media or filesystem failure, reinsert the exact removed drive promptly. DSM 7 can offer online assembly for the affected pool. That exception should not be generalized to a drive that has actually failed or is producing repeated I/O errors.
For a crashed-volume incident, accidental drive removal has a special path changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Do not confuse a volume crash with a system partition failure
DSM can also report System Partition Failed on one or more disks. The system partition is mirrored separately from your data volume, and its repair logic is different. Read the exact Storage Manager message before deciding that a volume-level failure has occurred.
For a crashed-volume incident, do not confuse a volume crash with a system partition failure changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Memory errors can matter after the data is safe
Synology includes a memory test in its crashed-volume workflow after readable data has been backed up. Unstable memory can contribute to corruption symptoms. The order matters: preserve data first, then test platform components rather than stressing the system before an evacuation.
For a crashed-volume incident, memory errors can matter after the data is safe changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Drive health evidence should be preserved
Capture screenshots of drive health, serial numbers, bad-sector counts, I/O logs and which physical bay contains each disk. That record becomes useful if a later test requires moving a suspected drive or if the system must be rebuilt on another chassis.
For a crashed-volume incident, drive health evidence should be preserved changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
A new pool means the old storage metadata is gone
Removing the crashed storage pool and creating a new one is a destructive transition. Only take that step after the data you need has been copied or after accepting that recovery will be handled separately from the original disks.
For a crashed-volume incident, a new pool means the old storage metadata is gone changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Backups change the risk calculation
A recent verified Hyper Backup, snapshot replica or offline copy turns a crash into a rebuild exercise rather than a data-rescue emergency. Validate that the backup can actually be opened or restored before wiping the damaged storage, especially if the backup target depends on the same NAS.
For a crashed-volume incident, backups change the risk calculation changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Replacement drives should match the recovery plan
If drive errors contributed to the crash, do not automatically reuse suspect media in the recreated pool. Check Synology compatibility, warranty status, SMART evidence and the age of the rest of the set. A crash can be the right moment to replace multiple aging drives rather than rebuild around another near-term failure.
For a crashed-volume incident, replacement drives should match the recovery plan changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Escalate when uncertainty becomes expensive
If the data is unique, encrypted, financially valuable or required for business continuity, conservative escalation is rational. Synology support can help with platform diagnostics, while professional recovery services are the appropriate path when the volume is unreadable and no valid backup exists.
For a crashed-volume incident, escalate when uncertainty becomes expensive changes the recovery sequence because every write can alter the evidence left on the affected filesystem. Capture the current Storage Manager screen, note which files still open, and rescue the highest-value readable folders before testing components. If this checkpoint would require deleting the crashed pool or creating a replacement volume, postpone that destructive boundary until the copied data has been opened successfully somewhere else. The crash workflow should always leave a clearer recovery position than the one you started with.
Questions people ask
Synology Volume Crashed questions
Can a crashed Synology volume be repaired?
Synology says a volume crash caused by drive or filesystem errors cannot be repaired through the normal in-place repair workflow. If data is readable, copy it first and rebuild storage afterward.
A crashed-volume question should be answered from the current readability state, not from a generic RAID assumption. Preserve readable files before pool recreation.
Should I reboot a crashed Synology NAS?
Do not make repeated reboots your first response. Record the state and, when data is readable, prioritize copying it. A reboot may change availability without solving underlying filesystem or media damage.
What if File Station still opens my files?
That is the best recovery window. Copy irreplaceable data to another machine or independent storage destination before deleting or recreating the affected pool.
What if File Station cannot read the data?
Avoid destructive experiments. Synology recommends seeking data-rescue assistance when the NAS is accessible but the crashed volume data cannot be read.
Can I run data scrubbing on a crashed volume?
Do not treat data scrubbing as a universal crash repair. Scrubbing is appropriate only in specific healthy or reassembled conditions; a true crashed filesystem requires a different recovery decision.
Does SHR protect me from a crashed volume?
SHR provides redundancy against supported drive failures, but redundancy is not a backup and does not make filesystem corruption or multiple failures impossible.
What if I accidentally pulled a drive?
Reinsert the exact drive and follow DSM's online-assemble guidance when the crash was caused by accidental removal. Do not substitute a different drive casually.
Should I replace a drive before copying data?
If the crashed volume is still readable, prioritize copying important data before introducing avoidable changes unless Synology support specifically directs otherwise.
Can bad RAM cause storage corruption?
Memory instability can contribute to corruption symptoms. Synology includes a memory test in its crash workflow after readable data has been secured.
When should I use professional recovery?
When the data is irreplaceable, the volume is unreadable, multiple disks are failing, encryption complicates access or you are unsure which action could overwrite recoverable metadata.
Official references and methodology
Verify the live DSM state before any destructive recovery step
This crash guide is organized around preservation before reconstruction. It follows Synology's current crashed-volume guidance, distinguishes a crashed volume from a merely degraded pool, and treats a readable filesystem as a short window for copying important data. Menu names and available actions vary by DSM build, filesystem and storage layout, so the live Storage Manager state should be recorded before any pool or volume is removed.
- Synology: What can I do if one of my volumes crashed?
- Synology: Repair a storage pool
- Synology: Determine whether errors come from the drive or slot
As an Amazon Associate, Cloudzat may earn from qualifying purchases. Failure states, DSM behavior, migration compatibility and recovery options can change by model and DSM build. Preserve readable data and verify Synology's current Knowledge Center instructions before initializing drives, deleting pools, reinstalling DSM or changing the only copy of important data.