Synology NAS Failure: The Data Recovery Process and the Special Case of SHR

TL;DR: Synology NAS devices build the DSM (DiskStation Manager) operating system on top of Linux mdadm RAID, LVM2 and, on modern models, the Btrfs file system. SHR (Synology Hybrid RAID), unlike classic RAID 5, uses a multi-segment structure and is designed to use disks of different sizes efficiently. If the NAS will not power on, if DSM will not boot, or if the volume reports "crashed", the raw data on the disks is typically still intact. The most critical rule is to never press the "Reinitialize" or "Repair" button in the panel, but instead to label the disks in slot order and move them to a professional laboratory. In installations that have Btrfs snapshots, partial recovery is much easier.

This article is the Synology NAS branch of the Data Recovery Guide 2026 pillar guide, and it covers crashes, data loss and SHR special cases on DSM-based systems.

The 5 most common failures on a Synology NAS

Typical scenarios compiled from field observation:

  1. Single disk failure, array degraded: SMART errors increase and DSM issues a "Storage Pool degraded" warning. The array is still up, but it has no remaining disk protection.
  2. Two disks lost at the same time: In a RAID 5 / SHR-1 structure, the array goes down when the second disk fails. Because they are usually disks from the same batch that have aged over a similar number of operating hours, they tend to fail in series.
  3. Will not boot after a DSM upgrade: The update stops halfway and the bootloader or the system partition (md0) is corrupted. The disks continue to hold the data; the problem is in the software layer.
  4. "Reinitialize" clicked by mistake: In a moment of panic, the "Repair" or "Reinitialize Storage Pool" button is pressed. The mdadm superblock and the LVM metadata are overwritten.
  5. Btrfs subvolume corrupted: A sudden power outage, bad memory or a disk error corrupts the Btrfs metadata tree. The volume will not mount and DSM reports "Volume crashed".

The DSM infrastructure in brief

Although DSM has a commercial shell, its core layer consists of standard Linux components. The official architecture documents and the Synology Knowledge Center state this clearly:

  • mdadm RAID (Linux software RAID), read via /proc/mdstat. It is the core array layer.
  • LVM2 provides logical volumes on top of the mdadm array. The multi-segment structure of SHR is built in this layer.
  • Btrfs (newer models, the DS+ and enterprise line) or ext4 (older / entry-level models) is the file system.

When the recovery analysis begins, the first files examined in the laboratory are: /proc/mdstat (active RAID), /etc/lvm/backup/ (LVM metadata backups), /etc/space/space_history.xml (DSM's storage pool history), /var/log/messages and /var/log/space_operation_error.log. These files show how the array was built and when it last operated in a healthy state.

The difference between SHR and classic RAID 5

Synology Hybrid RAID is not just a simple shell over classic RAID 5. To use disks of different sizes efficiently, SHR splits the disks into segments and builds a separate mdadm RAID set for each segment. For example, in an SHR-1 array built with 4 TB, 4 TB, 6 TB and 8 TB disks, there are multiple md devices in the underlying layer, and these are combined with LVM and presented as a single volume.

This structure is practical for the user, but it means extra work for recovery. Classic RAID 5 tools (ReclaiMe, R-Studio, the standard RAID mode of UFS Explorer) cannot read an SHR array as a single array. Each segment must be extracted separately and combined in the correct order at the LVM layer. The Linux mdadm wiki is the fundamental reference for resolving these combined structures, but knowing Synology's LVM layout requires practical experience.

SHR-2, on the other hand, is the multi-segment version of classic RAID 6 and tolerates the failure of two disks. The same segment logic applies in recovery; only the parity calculation is doubled.

NAS crashed: the first 30 minutes

If the device is beeping, DSM will not start, or the volume reports "crashed", what you do in the first half hour determines the data loss:

  1. Power off the device. Hold the power button to shut down safely; if it will not shut down, unplug it. A NAS that is left on may attempt a rebuild and corrupt the state of the data.
  2. Label the disks in slot order. Write "Slot 1, Slot 2..." with tape. If the order is mixed up, the SHR segment map becomes impossible to reconstruct.
  3. Do not press any button in the panel. The "Repair", "Reinitialize" and "Recreate Storage Pool" buttons typically overwrite the metadata.
  4. Save the logs. If the device still partially powers on, download the log package via DSM Support Center, or copy the files under /var/log/.
  5. Note the SMART status. If possible, write down which disk has a Status of "Warning / Critical".
  6. Check whether you have a backup. Seeing when Hyper Backup, Cloud Sync or an external USB backup was last taken speeds up planning.
  7. Go to a professional laboratory. Especially in SHR and encrypted volume cases, attempting recovery under home conditions makes the job harder.

A disk failed: what happens if I insert a new disk?

When a single disk fails, the array enters degraded mode. When a new disk is inserted, DSM starts a rebuild. During the rebuild, a full read is performed from all of the remaining disks, and this is the weak moment of RAID 5 / SHR-1. The URE (Unrecoverable Read Error) mathematics is brutal on large disks: on a modern 8 TB disk, the probability of a sector read error during the rebuild is not low, and a second read error brings the array down completely.

For this reason, the practical recommendation is to take a sector-by-sector image of the existing disks before starting the rebuild, and to attempt the rebuild on the images without touching the original disks. For the mathematics and pricing of the classic RAID 5 scenario, see the separate article: RAID 5 Failure.

Will not boot after a DSM upgrade

When a DSM update stops halfway or the power is cut, a NAS that will not boot can look like a cause for panic. In reality, on Synology NAS devices the boot partition is a separate md device (usually md0) and is independent of the data volume. The disks continue to hold the data.

In the typical case, the work done in the laboratory is: cloning the disks, connecting the clones to a Linux workstation, assembling the data array with mdadm, activating the LVM volume, and mounting it read-only as Btrfs / ext4. After the data is extracted, the device can be reinstalled from scratch and the data restored. A corrupted boot almost never means data loss, as long as no one pressed a button and chose "Reinitialize".

"Reinitialize" clicked by mistake

This is one of the most frequently heard scenarios in consultation calls. The user presses the "Repair" or "Reinitialize Storage Pool" button, and DSM enters the process of building a new array.

If the process was quickly stopped in sequence, there is still a chance of recovery, because overwriting the actual file blocks takes hours; what is deleted first is the mdadm superblock and the LVM metadata. The raw data on the disks is still there on the NAND / HDD platter; only the road map has been erased. In the laboratory, the array can be extracted again through metadata reconstruction.

If the DSM rebuild completed after "Reinitialize" and a long period of writing took place, the chances decrease. That is why, the moment the button is pressed, the device must be powered off immediately and nothing must be read or written.

Btrfs subvolume recovery

Modern Synology models use the Btrfs file system. The official Btrfs documentation describes Btrfs's copy-on-write (COW), checksum-based integrity and snapshot mechanism. DSM reflects these features in the field through the "Snapshot Replication" tasks that the user sets up.

When a volume crashes, the situation is as follows:

  • If a snapshot exists: The previous consistent snapshot is mounted and the files are extracted. This is the fastest way out in most software-induced corruption.
  • If there is no snapshot but the metadata is partially intact: Tree repair is attempted with the btrfs check, btrfs restore and btrfs-progs toolset. These operations are performed on a read-only copy.
  • If the metadata is heavily corrupted: File carving comes into play; raw data is gathered from the sectors based on file-type signatures. The folder structure and file names may be lost, but the content is recovered.

Thanks to Btrfs's COW structure, old block versions remain on the disks for a while, and under laboratory conditions these remnants are valuable.

The volume is encrypted and the key is lost

DSM's "Shared Folder Encryption" and volume-level encryption features are common. The encryption key is typically stored locally within DSM, and the device requests a password at startup.

The scenarios are:

  • The password is known and the key file exists: The standard process is resumed, and the recovery proceeds like other NAS failures.
  • The password is forgotten and there is no backup key file: The raw content of the encrypted volume is protected with AES. Brute force is not a practically viable path.
  • There is a backup key file (DSM "Export Encryption Key"): This file can be imported to open the volume again.

For this reason, in enterprise installations it is critical to store the encryption key securely, in a location separate from the offensive geography.

The Synology recovery process step by step

The laboratory process follows the same backbone regardless of the structure:

  1. Slot labeling and intake. The disks are registered one by one by serial number.
  2. Sector-level imaging. A bit-by-bit clone of each disk is created. The work proceeds on the images; the original disks are never written to again.
  3. mdadm metadata analysis. The superblocks are read and the array geometry (chunk size, disk order, level) is verified.
  4. LVM and SHR segment map. If it is SHR, the md devices of the different segments are assembled one by one and the LVM physical volumes are combined.
  5. File system layer. If it is Btrfs, a read-only mount is attempted, with btrfs restore if necessary. If it is ext4, a mount is performed after journal replay.
  6. Subvolume / snapshot rebuild. If there are snapshots on Btrfs, it is possible to go back in time.
  7. Verification. Critical files (DB dumps, office documents, images, video) are opened to confirm their integrity.
  8. Delivery and destruction. The customer data is written to new media, and the laboratory copies are erased using the NIST SP 800-88 Purge methods.

What determines the cost?

Synology recovery prices do not follow a fixed list, because no two cases are typically alike. The main factors that determine the price:

  • Number of disks and total capacity: The imaging time grows linearly with the disks.
  • Type of structure: Classic RAID 1/5/6, SHR-1, or SHR-2. Because SHR is multi-segment, it requires additional engineering.
  • File system: Btrfs (snapshots, COW, checksums) generally requires more complex analysis than ext4.
  • Encryption: If the key exists the difference is small; if there is no key, the case is almost always in the difficult category.
  • Physical damage: If one of the disks has a head failure, a scratched platter or a burned-out circuit board, donor parts and clean-room work are added.
  • Urgency: Priority tiers such as standard, fast and critical affect the price according to how much the duration is shortened.

Which Synology models do we have experience with?

In the DSET laboratory, work has been carried out on a wide range of models, from the home / SOHO line to the enterprise line:

  • Entry and home: DS220+, DS224+, DS418, DS420j, DS423+
  • Professional desktop: DS920+, DS923+, DS1522+, DS1621+, DS1821+
  • High-end consumer and small business: DS2422+, DS3622xs+
  • Rack and enterprise: RS1221+, RS1619xs+, RS3621xs+, RS4021xs+, FS-series flash models

Our field experience covers DSM 6.x and DSM 7.x installations, both ext4 and Btrfs volumes, and both classic RAID and SHR / SHR-2 arrays.

KVKK and confidentiality

A corporate NAS almost always holds personal data within the scope of KVKK (Turkish Personal Data Protection Law No. 6698): employee files, customer records, accounting databases, camera archives. Before delivery to the laboratory a written NDA is signed, the work is carried out in an isolated, internet-disconnected (air-gapped) environment, and access is logged.

When the job is finished, the laboratory copies are erased at the NIST SP 800-88 Purge level. This international standard is the accepted destruction reference for magnetic and flash media, and it is consistent with KVKK's obligation of "destruction of data once it has fulfilled its purpose".

Frequently Asked Questions (FAQ)

DSM will not boot, will the data be lost?

Typically no. The boot partition and the data volume are separate md devices. Even if the device will not power on, the disks hold the data. What is critical is not to press the "Reinitialize" button in the panel.

Can you recover SHR like classic RAID 5?

SHR is a multi-segment structure, and classic RAID 5 tools cannot read it as a single array. In the laboratory, the md device of each segment is assembled separately and combined at the LVM layer, after which the file system is mounted.

Can an old version of a file be recovered without a Btrfs snapshot?

If there is no snapshot, the chance of recovering an old version decreases, but thanks to Btrfs's copy-on-write structure, old blocks remain on the disk for a while. Partial recovery is attempted with file carving.

Is it possible to recover an encrypted volume?

If the password or an exported key file exists, it is practically no different from other cases. If the key is completely lost, breaking AES in practice is not possible.

Two disks failed at the same time, is there hope?

In SHR-1 / RAID 5, if two disks have genuinely failed the situation is difficult, but not hopeless. Usually one of the disks has not died completely and has only given read errors. When a partial image of the weak disk is taken and placed into the array in the laboratory, recovery can be achieved.

How long does it take?

It varies according to disk health, capacity, structure and encryption. A typical two-to-four-disk SHR-1 case is usually completed within a few business days. If there is physical damage, the duration is longer.

I had intended to make a backup but could not, will it still be attempted?

Yes. When the device crashes, the absence of a backup can look like a cause for panic, but the raw data on the disk platters / NAND is still there. What matters is not writing new data over it.

Working with DSET

DSET (Doğanay Cyber Security Technologies), at its laboratory located in Hacettepe Teknokent, Ankara, carries out sector-level imaging, mdadm reconstruction, SHR segment assembly, LVM activation and Btrfs repair processes for Synology DSM-based NAS systems. For a general guide, the Data Recovery Guide 2026 and, for classic RAID 5 arrays, the RAID 5 Failure article provide additional reading.

If the device is beeping, reports "Volume crashed", or DSM will not start, call before you press the panic button: +90 536 662 38 09, Hacettepe Teknokent, Ankara.

Sources: Synology Knowledge Center, Linux mdadm RAID wiki, Btrfs documentation, KVKK, NIST SP 800-88 Rev. 1