Cloner un ordinateur portable via NVMe TCP

Clonage d’un ordinateur portable avec NVME TCP

• J’ai récemment acheté un nouvel ordinateur portable et j’ai dû le configurer pour pouvoir l’utiliser.
• Je n’avais aucune envie de répéter des étapes déjà bien connues.
• Sur la suggestion d’un collègue, j’ai envisagé de copier le disque existant vers le nouveau portable.

Questions sur le processus de clonage

• Je n’avais pas d’outil pour ouvrir l’ancien portable et connecter le nouveau disque en USB.
• J’utilise le chiffrement complet du disque, et l’ancien portable a un NVME de 512GB tandis que le nouveau utilise un NVME de 1TB.
• Je ne suis pas à l’aise avec le redimensionnement d’une partition LUKS.

Suggestion du collègue

• Il a suggéré d’utiliser NVME over TCP pour partager le disque via le réseau et effectuer une copie complète du disque.
• Les étapes proposées étaient les suivantes :
  • exporter le disque depuis l’ancien portable avec nvmet-tcp.
  • effectuer la copie du disque vers le nouveau portable.
  • redimensionner les partitions pour utiliser l’ensemble du 1TB.
  • redimensionner LUKS.
  • enfin, redimensionner le disque racine BTRFS.

Exporter le disque via NVME TCP

• L’utilisation de systemd-storagetm.service a été proposée comme la méthode la plus simple.
• À la place, les deux portables ont été démarrés sur un CD de secours GRML, puis les étapes ont été réalisées avec le module nvmet-tcp pour exporter le disque NVME.

Copie du disque

• La commande dd a été utilisée pour copier le disque racine vers le nouveau portable.
• Comme le nouveau portable n’avait pas de port Ethernet, il a fallu utiliser uniquement le Wi-Fi, et la copie complète des 512GB a pris environ 7 heures et demie.
• La vitesse de copie était d’environ 18-20MB/s.

Redimensionnement des partitions et du conteneur LUKS

• Lors de l’exécution de parted, celui-ci a détecté que la table de partitions ne correspondait pas à la taille du disque et a demandé une correction.
• cloud-guest-utils a été installé afin d’utiliser growpart pour étendre la partition jusqu’à 1TB.
• cryptsetup-resize a été utilisé pour augmenter la taille du conteneur LUKS.
• Après connexion au système, la taille du système de fichiers BTRFS a été redimensionnée.

Conclusion

• Le seul avantage de ce processus est de pouvoir utiliser le nouveau portable tout en ayant l’impression d’utiliser l’ancien.
• Configurer un nouveau portable prend généralement entre une et deux semaines, mais dans ce cas ce temps a pu être économisé.
• Un autre avantage est d’avoir appris à exporter un disque avec NVME over TCP.

Avis de GN⁺

• Le clonage d’un ordinateur portable via NVME over TCP propose une méthode efficace pour migrer rapidement un environnement système existant vers un nouveau matériel.
• Cette technique peut intéresser les administrateurs système et les développeurs comme moyen de gagner du temps et de réduire les erreurs de configuration.
• Elle dépend toutefois fortement de la vitesse du réseau, et si seul le Wi-Fi est disponible, le processus peut prendre beaucoup de temps, ce qui constitue un inconvénient à prendre en compte.
• Des outils comme Clonezilla ou Acronis offrent des fonctions similaires, mais NVME over TCP présente l’avantage particulier d’un accès direct au disque via le réseau.
• L’adoption de cette technique nécessite de bonnes connaissances sur la configuration réseau, la gestion des disques chiffrés et le redimensionnement des systèmes de fichiers.

[GN⁺]

Commentaire Hacker News

• Dans le scénario de l’auteur, il n’y a aucun avantage à utiliser NVMe/TCP. Comme il ne fait qu’une copie bloc série avec dd, il ne profite pas des E/S simultanées. Les commandes complexes peuvent simplement être remplacées par netcat.

  • Sur le portable de destination, utiliser $ nc -l -p 1234 | dd of=/dev/nvme0nX bs=1M.
  • Sur le portable source, utiliser $ nc x.x.x.x 1234 </dev/nvme0nX.
  • Côté destination, dd met en tampon les écritures, ce qui rend l’opération plus rapide et plus efficace. En ajoutant gzip/gunzip côté source/destination, toute l’opération devient bien plus rapide si le disque n’est pas plein. C’est ma méthode préférée pour créer une image de PC via le réseau. Il vaut mieux passer l’option --fast à gzip, ou le remplacer par lz4/unlz4, plus rapide. Je m’en suis servi récemment pour faire l’image d’un nouveau portable Windows avec un NVMe de 1 To ; via GigE, cela a pris environ 20 minutes, et l’image finale faisait 20 Go. En général, je sauvegarde cette image lz4, puis quelques années plus tard, quand je donne le portable, je la restaure avec unlz4 | dd. C’est très pratique.
  • Je ne connaissais pas le module du noyau Linux nvme-tcp, mais on apprend quelque chose de nouveau chaque jour. Son intérêt semble davantage être de monter un système de fichiers sur un NVMe distant que d’y accéder en brut avec dd.
  • Sous Linux, la taille maximale du tampon de tube est de 64 kB, donc l’argument dd bs=X n’a techniquement pas besoin d’être supérieur. Cela dit, bs=1M ne fait pas de mal (il tamponne les lectures de 64 kB jusqu’à atteindre 1 Mo) et reste utile à l’avenir si la taille des tubes augmente. Certaines versions de netcat disposent d’options pour contrôler la taille des blocs en entrée et en sortie, ce qui réduit le besoin d’utiliser dd bs=X, mais sur un disque de secours de restauration, on se retrouve souvent avec un binaire netcat qui n’a pas ces options.

• Utiliser nbdkit et nbdcopy est bien plus simple.

  • nbdkit file /dev/nvme0n1
  • nbdcopy nbd://otherlaptop localfile

• Quand j’ai dû configurer un nouveau portable, il a été utile d’utiliser un câble USB-C pour transférer à 10 Gb/s. L’autre option, c’était seulement le Wi‑Fi.

  • En reliant les ordinateurs, un réseau ad hoc se forme et on peut transférer avec rsync. Le lien semblait déjà saturé, donc utiliser un autre protocole n’aurait pas servi à grand-chose.

• J’ai récemment dû copier environ 200 Go de fichiers via le Wi‑Fi. J’ai utilisé rsync pour éviter de repartir de zéro en cas de coupure de connexion, mais cela a quand même pris au moins 6 heures. Je me demande s’il existe une meilleure méthode.

  • Avec la méthode dd, quelles garanties obtient-on ? Faut-il comparer le md5 du périphérique bloc obtenu ?

• Je ne comprends pas pourquoi l’auteur n’a pas simplement fait transiter btrfs sur le réseau. Il suffit d’abord de créer un instantané btrfs, puis de faire btrfs send => nc => network => nc => btrfs receive pour ne transférer que les blocs effectivement utilisés.

• La fois précédente où j’ai migré un portable, j’ai lancé un programme d’installation qui combinait dd et nc aux deux extrémités. De mémoire, j’y avais aussi ajouté gzip pour accélérer le transfert.

  • Comme le nouveau portable n’avait pas de port Ethernet, la compression a peut-être apporté un léger gain de vitesse, donc c’était probablement plus rapide que la méthode de l’auteur.

• Avec Clonezilla, on peut copier uniquement les blocs de données réels et ajuster automatiquement les partitions. C’est la méthode que j’utilise toujours.

  • En général, je retire le disque NVMe du portable et je le mets dans une station d’accueil rapide.

• Cela fait des décennies que je n’ai pas vraiment « installé » un OS ; je copie les fichiers puis j’ajuste ce qu’il faut. En général, j’en profite pour créer un nouveau système de fichiers afin de mettre à jour le type ou les paramètres du système de fichiers (par exemple la taille des blocs), le chiffrement, etc., puis je transfère les fichiers avec rsync.

  • Cela dit, pour ceux qui planifient ce genre de choses, il vaut peut-être mieux adopter une approche plus déclarative comme NixOS. On peut alors simplement copier la configuration, puis tout réinstaller automatiquement.

• Aucune mention de FDT (Fast Data Transfer).

  • Malheureusement, c’est un logiciel remarquable (du point de vue des performances de transfert) écrit en Java. Ses options de CLI ne sont pas intuitives, mais c’est le transfert le plus rapide que j’aie jamais vu.
  • C’est tellement rapide que, si on ne bride pas artificiellement le débit, il arrive parfois à monopoliser tout le réseau local.
  • L’option -limit <rate> permet de limiter le débit à une vitesse donnée. On peut utiliser les suffixes K (KiloBytes/s), M (MegaBytes/s) et G (GigaBytes/s).
  • Cela provoque de la fragmentation des fichiers côté destination, mais en pratique, cela n’a d’importance pour personne.