DB-유

Recovering Data from a Synology Disk on a Linux PC

· synology, linux, recovery

A dead Synology with healthy disks is a bad day, but not a lost one. DSM uses standard Linux mdadm RAID, LVM and ext4 or Btrfs, so an ordinary Linux PC can assemble the array and mount the volume read-only. I find that reassuring. No proprietary tools, just enough SATA ports or USB adapters to connect every member of the array at once. I use an Ubuntu 20.04 live USB.

Work read-only. Nothing here writes to the disks, and keep it that way until the data is safely copied.

What you need: all the array's disks connected (RAID 5/SHR survives one missing, not two), the Ubuntu 20.04 Desktop USB, a destination disk with enough space, and internet in the live session to install packages.

Boot and install the tools

Boot the live USB, choose Try Ubuntu, open a terminal:

sudo apt update
sudo apt install -y mdadm lvm2 btrfs-progs

Then identify the Synology disks:

lsblk -o NAME,SIZE,FSTYPE,LABEL
sudo fdisk -l /dev/sdb

Each DSM disk has three partitions: a 2.4 GB system partition (sdX1), a 2 GB swap (sdX2) and the large data partition (sdX3 or sdX5 on older layouts). The data partitions are the RAID members you care about.

Assemble the RAID

Let mdadm scan every partition and assemble what it finds, read-only:

sudo mdadm --assemble --scan --readonly
cat /proc/mdstat

Typical result:

md2 : active (read-only) raid5 sdb3[0] sdc3[1] sdd3[2] sde3[3]
      11720661504 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

If the scan does not assemble because a member is missing, force it with the members you have:

sudo mdadm --assemble --readonly --run /dev/md2 /dev/sdb3 /dev/sdc3 /dev/sdd3

Check each member first if unsure: sudo mdadm --examine /dev/sdb3 prints the array UUID, level and role, so you can tell which partitions belong together. SHR volumes with mixed disk sizes produce several md devices (md2, md3, ...), which LVM joins in the next step.

LVM, if there is any

SHR and any volume created with "multiple volumes on RAID" put LVM on top of mdadm:

sudo vgscan
sudo vgchange -ay
sudo lvs

You should see a volume group named vg1 (or vg1000 on older units) with a logical volume volume_1. Plain RAID volumes without LVM skip this step; the filesystem sits directly on /dev/md2.

Mount it read-only

Find the filesystem type and mount read-only:

sudo blkid /dev/vg1/volume_1
sudo mkdir -p /mnt/syno

For ext4:

sudo mount -o ro,noload /dev/vg1/volume_1 /mnt/syno

For Btrfs:

sudo mount -o ro,norecovery /dev/vg1/volume_1 /mnt/syno

(Use /dev/md2 instead of the LVM path when there is no volume group.) noload and norecovery prevent journal replay on a filesystem that was not cleanly unmounted, which keeps the mount strictly read-only.

Copy the data off

Shared folders appear as top-level directories:

ls /mnt/syno

Copy what you need to the destination disk with rsync so that an interrupted copy can resume:

sudo mount /dev/sdf1 /mnt/dest
sudo rsync -aHAX --info=progress2 --exclude='@eaDir' --exclude='#recycle' /mnt/syno/documents/ /mnt/dest/documents/

Excluding @eaDir skips the thumbnail cache, which can be enormous on photo shares. Btrfs snapshots are under /mnt/syno/@sharesnap/<share>/<timestamp> if you need an older version of something.

Cleaning up

sudo umount /mnt/syno
sudo vgchange -an
sudo mdadm --stop --scan

The disks can then go into the replacement Synology, which will recognize the volume and offer to migrate.

Don't skip the comparison

Before trusting the copy, compare file counts and a few checksums. I've regretted skipping this before:

find /mnt/syno/documents -type f ! -path '*/@eaDir/*' | wc -l
find /mnt/dest/documents -type f | wc -l
sha256sum /mnt/syno/documents/important.xlsx /mnt/dest/documents/important.xlsx

Counts should match once @eaDir and #recycle are excluded from both sides, and checksums must be identical.

When it doesn't cooperate

  • mdadm: /dev/md2 assembled from 2 drives - not enough to start the array: a RAID 5 with two missing members cannot be assembled. Check cabling and lsblk; a disk that is present but shows no partitions has a damaged partition table, not necessarily lost data, and needs professional help or a sector clone with ddrescue first.
  • mount: /mnt/syno: unknown filesystem type 'LVM2_member': you are mounting the md device instead of the logical volume. Activate LVM as above and mount /dev/vg1/volume_1.
  • Btrfs mount fails with open_ctree failed and dmesg shows parent transid verify failed: the filesystem metadata is inconsistent. Try mount -o ro,usebackuproot before anything destructive; btrfs restore can pull files off without mounting.
  • Filenames show up as ??? or Permission denied on homes: the ACLs reference UIDs from the NAS. As root you can read everything; add --no-perms to rsync if the destination cannot store them.

Try this once with an old disk before you need it for real. It's much calmer that way.