Migrating Synology data to a Debian NAS without losing anything

The starting point

DSM is an excellent product, but its limits eventually weigh: no custom kernel, packages tied to Synology's release cycle, and vendor lock-in that deepens over time. Debian hands back control over every layer and lets you automate with Ansible — provided you can first recover the existing data.

What's under the hood at Synology

Good news: DSM is built on standard Linux technology.

• mdadm for software RAID (Synology's "SHR" is mdadm with RAID 5)
• LVM for logical volumes
• Btrfs as the filesystem
• eCryptFS for shared-folder encryption

Bad news: Synology added a custom flag to Btrfs, the caseless flag, allowing case-insensitive filenames to keep SMB/Windows happy. The vanilla Linux kernel doesn't know it.

The Btrfs patch: caseless support

Without the patch, mounting fails:

BTRFS error: unrecognized feature flag: caseless

The fix is to compile a patched Btrfs module that recognises the flag. A btrfs_synology Ansible role automates the four steps: installing kernel headers and build tools, fetching the kernel sources matching the running version, applying the patch that adds caseless support, then compiling btrfs.ko and installing it via DKMS.

The patch itself is minimal: a few lines to declare the flag as known and treat it read-only. Creating new caseless files isn't needed, only reading existing ones. Once the module is loaded, the kernel accepts Synology Btrfs partitions.

Detecting and mounting the RAID

Synology uses mdadm in a standard way, so detection is automatic:

# Scan existing RAID arrays
mdadm --assemble --scan

# Check RAID state
mdadm --detail /dev/md2

Typical output for an SHR (RAID 5) across 4 disks:

/dev/md2:
        Version : 1.2
  Creation Time : Fri Mar 15 10:22:18 2024
     Raid Level : raid5
     Array Size : 5860270080 (5.46 TiB)
  Used Dev Size : 1953423360 (1.82 TiB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent
          State : clean
    Active Devices : 4
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 0
            Layout : left-symmetric
        Chunk Size : 64K

Then LVM activation:

# Scan and activate volume groups
vgscan
vgchange -ay

# List logical volumes
lvs

  LV   VG   Attr       LSize Pool Origin Data%  Meta%
  lv   vg1  -wi-a----- 5.46t

The /dev/vg1/lv logical volume holds the Btrfs filesystem, mounted with mount -t btrfs /dev/vg1/lv /mnt/data. To bring it all back at boot:

# /etc/fstab - mounting the Synology RAID
/dev/vg1/lv  /mnt/data  btrfs  defaults,noatime,autodefrag  0  0

The Ansible role also handles automatic assembly via /etc/mdadm/mdadm.conf.

eCryptFS: decrypting encrypted folders

If encryption was enabled on Synology shared folders, each encrypted folder is an @eaDir directory with eCryptFS files underneath:

# Mounting the eCryptFS layer
mount -t ecryptfs /mnt/data/@Family /mnt/data/Family \
  -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,\
ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=no

The system asks for the passphrase set in DSM. An ecryptfs_synology Ansible role automates it: passphrase stored in a secured file (600 permissions, root owner), automatic mounting of encrypted folders at boot via a systemd script, and support for several folders with different passphrases.

Samba: recreating the shares

Reusing the same share names as on the Synology means Windows/Mac clients notice nothing:

# /etc/samba/smb.conf (excerpt)
[Family]
    path = /mnt/data/Family
    valid users = @family
    read only = no
    create mask = 0664
    directory mask = 0775

[Images]
    path = /mnt/data/Images
    valid users = @family
    read only = no

[Music]
    path = /mnt/data/Music
    valid users = @family
    read only = no

[Videos]
    path = /mnt/data/Videos
    valid users = @family
    read only = no

Alongside the migrated data, create the directories for the new services:

# Directories for Docker applications
mkdir -p /mnt/data/apps
mkdir -p /mnt/data/media/{movies,tv,music}
mkdir -p /mnt/data/downloads/{complete,incomplete}
mkdir -p /mnt/data/photos

chown -R nasadmin:nasadmin /mnt/data/apps /mnt/data/media /mnt/data/downloads /mnt/data/photos

Watch out: Btrfs subvolumes

Btrfs organises data into subvolumes, and Synology creates one per shared folder. The trap: moving a file from one subvolume to another isn't a rename but a full copy followed by a delete. On multi-gigabyte files that's slow and temporarily doubles the space used.

# List the subvolumes
btrfs subvolume list /mnt/data

To move large files between shares, rsync beats mv: progress bar and resumable after an interruption.

Swap file on Btrfs

Creating a swap file on Btrfs requires disabling copy-on-write, otherwise the kernel refuses:

# Creating the swap file
truncate -s 0 /mnt/data/swapfile
chattr +C /mnt/data/swapfile
fallocate -l 4G /mnt/data/swapfile
chmod 600 /mnt/data/swapfile
mkswap /mnt/data/swapfile
swapon /mnt/data/swapfile

# fstab entry
# /mnt/data/swapfile  none  swap  sw  0  0

chattr +C must come before allocation.

Monthly scrub for integrity

Btrfs's scrub mechanism verifies the integrity of all data through checksums:

# /etc/systemd/system/btrfs-scrub.timer
[Unit]
Description=Monthly Btrfs scrub on /mnt/data

[Timer]
OnCalendar=monthly
Persistent=true
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target

# /etc/systemd/system/btrfs-scrub.service
[Unit]
Description=Btrfs scrub /mnt/data

[Service]
Type=oneshot
ExecStart=/usr/bin/btrfs scrub start -B /mnt/data
Nice=19
IOSchedulingClass=idle

Nice=19 and IOSchedulingClass=idle keep the scrub from disturbing normal usage.

Verdict

Migrating from Synology to Debian is entirely feasible, encryption included. The main obstacle is the caseless Btrfs flag: once the kernel is patched, the rest follows naturally. mdadm, LVM, Btrfs and eCryptFS are standard Linux tools that Synology assembled behind a web interface — handling them directly returns control and flexibility, without losing a byte.