Migration données ReadyNAS RN102 vers Linux récent


Après avoir monté un serveur NAS maison en remplacement de mon Netgear RN102, j'ai voulu mettre les deux disques en RAID1 md de mon précédent NAS dans mon serveur sous Archlinux à jour. Le processus est normalement trivial :

  • Éteindre le NAS
  • Brancher les disques sur le serveur Linux
  • Les grappes RAID md sont découvertes automatiquement et rendues accessible sur /dev/md et /dev/md/
  • Monter les systèmes de fichier Btrfs présent dans /dev/md*

Évidemment, si je fait un article c'est que ça s'est pas passé comme ça... dès que j'accédais à certains dossiers, j'obtenais les erreurs suivantes :

[11565.673863] BTRFS critical (device md126): corrupt leaf: root=1 block=1955138043904 slot=5, invalid root flags, have 0x10000 expect mask 0x1000000000001
[11565.673871] BTRFS error (device md126): block=1955138043904 read time tree block corruption detected
[11565.681895] BTRFS critical (device md126): corrupt leaf: root=1 block=1955138043904 slot=5, invalid root flags, have 0x10000 expect mask 0x1000000000001
[11565.681902] BTRFS error (device md126): block=1955138043904 read time tree block corruption detected

btrfsck ne remonte aucunes erreurs, et après des heures de galère impossible de trouver un correctif. En remettant les disques dans le NAS tout refonctionne parfaitement. Le problème se produit qu'avec des noyaux Linux "récents".

J'ai donc essayé de migrer les données entre le ReadyNAS et mon nouveau NAS via rsync sur SSH mais évidemment c'est trop long. Deuxième tentative avec tar+netcat pour éviter le chiffrement de SSH, toujours trop lent, CPU saturé pour environ 20MB/s.

Au final j'ai obtenu des résultats corrects en mettant les deux disques dans le NAS sous Arch et en migrant les données via une VM avec qemu. C'était l'occasion de tester qemu en CLI au lieu de via libvirt habituellement.

Pour la VM il faut :

  • Une version de noyau proche de celle de ReadyNAS OS (4.19.4)
  • Utiliser un live linux (évite une installation)
  • Les outils Btrfs
  • Supporte virtfs et virtio pour que le transfert soit rapide

L'image d'installation Archlinux 2018-12-01 coche toutes ces cases. Elle est facilement trouvable grâce à l'archive Archlinux

Machine hôte

Vérification de l'état des grappes RAID md

mdadm --detail /dev/md*

Arrêt de la grappe de données

mdadm --stop /dev/md126

Remise en service de la grappe de données avec qu'un seul disque.

--run est nécesaire pour forcer la mise en service avec qu'un seul disque

--readonly est pas obligatoire, mais ça évite les mauvaises manips

mdadm --assemble --run --readonly /dev/md126 /dev/sdb3

Démarrage de la VM

qemu-system-x86_64 -cdrom archlinux-2018.12.01-x86_64.iso -boot order=d -enable-kvm -machine q35 -cpu host -m 512M -drive file=/dev/md/md_data,format=raw,if=virtio,readonly -vga std -vnc :0 -virtfs local,id=dest,path=/mnt/data,security_model=none,mount_tag=dest -k fr -smp 4

Démarrer une ISO

-cdrom archlinux-2018.12.01-x86_64.iso -boot order=d

Options de virtualisation machine

-enable-kvm -machine q35 -cpu host -m 512M -smp 4

Partage de disques

-drive file=/dev/md/md_data,format=raw,if=virtio,readonly

J'ai pas eu la motivation d'utiliser la VM via port série, j'ai utilisé VNC

-vga std -vnc :0

Forcer la disposition des touches sur la VM

-k fr

Dans la VM

Montage des deux systèmes de fichier :

-o noatime permet de grapiller un peu de performance

-o trans=virtio force le mode de transport (pas sûr que ce soit nécessaire)

mkdir src dest
mount -t 9p -o trans=virtio,noatime dest dest
mount -t btrfs -o ro /dev/vda src

Copie des fichiers

-a pour copier les attributs des fichiers (propriétaires, permissions etc.)

rsync -a src/ dest

ou

cp -a src/* dest