My Synology DS216j got stuck in an endless “Welcome Back!” migration loop. Every time I booted it up, it insisted on installing a new version of DSM, but the process would loop or fail, leaving the NAS inaccessible.
Since the NAS OS lives on a hidden system partition across the drives, a failed update or corrupted metadata will lock you out entirely. To troubleshoot, I pulled the drives out, bought a USB-to-SATA adapter, and plugged them one by one into my Omarchy Linux laptop to see what was actually going on under the hood.
Running mdadm --examine on the system partitions (sdc1) revealed the reality: both drives had completely wiped or unreadable system superblocks. That explained why the NAS motherboard kept rejecting them—there was no recognizable OS header left to boot from.
Fortunately, Synology isolates the OS from your actual files. While Partition 1 (OS) and Partition 2 (Swap) were dead, Partition 5 (sdc5) held the main data volume wrapped in an LVM container over a software RAID array.
Using my Linux environment, I forced mdadm to spin up the data array in degraded mode using just a single drive, scanned for the LVM volume group (vg1000), and mounted the logical volume. All 288GB of my shared folders were completely intact. From there, it was a straightforward rsync job to copy everything over to my local NVMe drive.
With my data safely backed up to the laptop, the path forward is simple: put the drives back into the chassis, let the DS216j perform a clean DSM reinstallation to rebuild those dead system partitions, and restore the files from the local backup.
If your Synology is stuck in a boot loop and you need to bypass the chassis to rescue your files using a Linux machine, use this exact workflow.
lsblk
(Note your drive letter, e.g., sdc, and the partition numbers: sdc1 for the system, sdc5 for the data).
Ensure your system has the required utilities installed to handle Synology’s software RAID and LVM structure:
sudo pacman -S mdadm lvm2
Because you are reading a single drive from a multi-drive array, you must force the kernel to assemble the array in degraded mode:
sudo mdadm --assemble --run /dev/md127 /dev/sdc5
(Replace sdc5 with your actual partition path if your drive letter differs).
Scan for physical volumes and activate the Synology Volume Group:
sudo pvscan
sudo vgchange -ay
Verify the logical volume is active:
sudo lvs
(You should see your Volume Group, typically vg1000, and Logical Volume, typically lv).
Create a temporary mount point and mount the mapped storage:
sudo mkdir -p /mnt/syno_data
sudo mount /dev/mapper/vg1000-lv /mnt/syno_data
(Adjust vg1000-lv to match the exact names returned by lvs).
Use rsync to safely copy the data to your local machine with a progress bar:
mkdir ~/synology_backup
sudo rsync -aP /mnt/syno_data/ ~/synology_backup/
Once the transfer finishes, take ownership of the backup directory so you can access the files without sudo:
sudo chown -R $USER:$USER ~/synology_backup
Safely stop the RAID array and power down the USB bus before unplugging the drive:
sudo mdadm --stop /dev/md127
udisksctl power-off -b /dev/sdc
(Replace sdc with your drive letter).
From here, you can safely return the drives to your Synology enclosure, proceed with the fresh DSM operating system installation, and restore your data from ~/synology_backup.
Subscribe to get daily strategies.