Migrer ses données Synology vers un NAS Debian sans rien perdre

D'où j'arrive

J'ai passé plusieurs années sur un DS918+ Synology. C'est un excellent produit, vraiment. Mais à un moment donné, les limites commencent à peser. Impossible d'installer un kernel custom. Les packages qui dépendent du cycle de release de Synology. Et surtout ce vendor lock-in qui s'installe progressivement - chaque jour que tu restes, c'est plus compliqué de partir.

L'élément déclencheur ? La flexibilité. Avec Debian, tu choisis le hardware, tu contrôles chaque couche, tu automatises tout avec Ansible. Mais avant de profiter de tout ça, il faut d'abord récupérer les données existantes. Et là... ça se complique vraiment.

Ce qu'il y a sous le capot chez Synology

Bonne nouvelle : Synology n'a rien inventé d'exotique. DSM repose sur des technos Linux standard :

• mdadm pour le RAID logiciel (ce que Synology appelle SHR, c'est mdadm avec du RAID 5)
• LVM pour les volumes logiques
• Btrfs comme système de fichiers
• eCryptFS pour le chiffrement des dossiers partagés

Mauvaise nouvelle : Synology a ajouté un flag custom à Btrfs, le caseless flag. Il permet les noms de fichiers insensibles à la casse (pour que SMB/Windows soient heureux). Ce flag ? Le kernel Linux vanilla n'en sait rien.

Le patch Btrfs : support du caseless

Sans ce patch, boum :

BTRFS error: unrecognized feature flag: caseless

Le kernel refuse simplement. Du coup, solution : compiler un module Btrfs patché qui reconnaît ce flag. J'ai créé un rôle Ansible btrfs_synology qui automatise tout :

1. Installation des headers du kernel et des outils de build
2. Récupération des sources kernel correspondant à la version en cours
3. Application du patch qui ajoute le support caseless
4. Compilation du module btrfs.ko et installation via DKMS

Le patch lui-même ? Minimalist. Quelques lignes pour déclarer le flag comme connu et le traiter en lecture seule. On n'a pas besoin de créer de nouveaux fichiers caseless, juste de lire ceux qui existent. Une fois le module installé et chargé, le kernel accepte les partitions Btrfs Synology sans protester.

Détection et montage du RAID

Synology utilise mdadm de façon standard. La détection se fait automatiquement :

# Scan des arrays RAID existants
mdadm --assemble --scan

# Vérification de l'état du RAID
mdadm --detail /dev/md2

Résultat typique pour un SHR (RAID 5) sur 4 disques :

/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

Ensuite, on active LVM :

# Scan et activation des volume groups
vgscan
vgchange -ay

# Listing des volumes logiques
lvs

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

Le volume logique /dev/vg1/lv contient notre système de fichiers Btrfs. On le monte :

mount -t btrfs /dev/vg1/lv /mnt/data

Rendre tout permanent

Pour que tout remonte automatiquement au boot :

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

Le rôle Ansible gère aussi la configuration de mdadm pour l'assemblage automatique via /etc/mdadm/mdadm.conf.

eCryptFS : déchiffrer les dossiers chiffrés

Si vous aviez activé le chiffrement sur vos dossiers partagés Synology, chaque dossier chiffré est un répertoire @eaDir avec des fichiers eCryptFS en dessous. Deux étapes pour déchiffrer :

# Montage de la couche eCryptFS
mount -t ecryptfs /mnt/data/@Famille /mnt/data/Famille \
  -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,\
ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=no

Le système demande la passphrase (celle que vous aviez définie dans DSM). J'ai automatisé ça dans un rôle Ansible ecryptfs_synology qui :

• Stocke la passphrase dans un fichier sécurisé (permissions 600, root owner)
• Monte automatiquement les dossiers chiffrés au boot via un script systemd
• Supporte plusieurs dossiers chiffrés avec des passphrases différentes

Samba : recréer les partages

Les données sont montées. Maintenant il faut les mettre sur le réseau. J'ai recréé les mêmes noms de partage que sur le Synology pour que les clients Windows/Mac ne remarquent rien :

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

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

[Musiques]
    path = /mnt/data/Musiques
    valid users = @famille
    read only = no

[Vidéos]
    path = /mnt/data/Vidéos
    valid users = @famille
    read only = no

Les partages migrés : Coco, Famille, Images, Lalitha, Logiciels, Matthias, Musiques, Vidéos, Téléchargements. Avec les bons droits par groupe.

Créer les nouveaux répertoires

En plus des données migrées, je crée des répertoires pour les nouveaux services :

# Répertoires pour les applications Docker
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

Tout sur le RAID, sur le même volume Btrfs.

Attention : les subvolumes Btrfs

Btrfs organise les données en subvolumes, et Synology en crée un par dossier partagé. Le piège : déplacer un fichier d'un subvolume à l'autre n'est pas un rename - c'est une copie complète puis une suppression. Sur des fichiers de plusieurs Go, ça devient très long et consomme le double d'espace temporairement.

# Lister les subvolumes
btrfs subvolume list /mnt/data

Donc si tu dois déplacer de gros fichiers entre partages, utilise rsync plutôt que mv. Tu auras une barre de progression et tu pourras reprendre en cas d'interruption.

Swap file sur Btrfs

Créer un fichier swap sur Btrfs demande une précaution : tu dois désactiver le copy-on-write sur le fichier, sinon le kernel refuse :

# Création du 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

# Entrée fstab
# /mnt/data/swapfile  none  swap  sw  0  0

Le chattr +C désactive le CoW avant d'allouer. C'est indispensable.

Scrub mensuel pour l'intégrité

Btrfs a un mécanisme scrub qui vérifie l'intégrité de toutes les données en vérifiant les checksums. Je le lance mensuellement :

# /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

Le Nice=19 et IOSchedulingClass=idle garantissent que le scrub ne perturbe rien.

Et voilà

La migration depuis Synology vers Debian est tout à fait faisable, même avec chiffrement. L'obstacle principal, c'est ce flag Btrfs caseless - une fois le kernel patché, le reste suit naturellement. mdadm, LVM, Btrfs, eCryptFS : ce sont tous des outils Linux standard que Synology a assemblés avec une interface web par-dessus. En les manipulant directement, tu gagnes en contrôle, en flexibilité, et tu gardes chaque byte de tes données.