GuiGui's Show

Système non chiffré mono-partition, sans volumes logiques

Je dispose d'une sauvegarde au format tar de toute l'arborescence. Attention aux UID/GID, aux file capabilities et aux chemins relatifs lors de la création de cette sauvegarde.

Pour la restaurer sur une machine virtuelle de même architecture (exemple : amd64) fraîchement déployée et fonctionnant avec le même système d'exploitation (exemple : Debian GNU/Linux Stretch) :

• Restaurer la sauvegarde, en root : cd / && tar xf sauvegarde.tar.lzma --xattrs --xattrs-include='*' ;
  
  
• Corriger /etc/fstab si la désignation de la partition a changé (utiliser blkid pour obtenir le nouvel UUID de la partition) puis mettre à jour l'initramfs avec update-initramfs -u -k all ;
  
  
• Changer la configuration réseau dans /etc/network/interfaces ;
  
  
• grep -R '<anciennes_IPv4_et_v6>' /etc pour vérifier que les anciennes adresses IP ne traînent pas dans des configurations.

Système chiffré multi-partitions (« /boot » en clair et « / » chiffrée), sans volumes logiques

Je pourrais utiliser la même méthode que pour un système non chiffré, mais cela nécessite au préalable de reformater la machine virtuelle (afin d'avoir deux partitions) et d'écraser le système par un conteneur chiffré dans lequel je décompresserai ma sauvegarde. Ceux que cette piste intéresse peuvent s'inspirer de la documentation suivante : Stockage chiffré intégral sur serveur distant.

Autre méthode :

• Démarrer la nouvelle machine virtuelle sur un système minimaliste comme un liveCD ou le mode rescue d'un hébergeur ;
  
  
• Exploser la table des partitions de la nouvelle machine (avec dd if=/dev/zero, of=/dev/sdX, par ex.) et informer le noyau de ce changement : apt-get install parted && partprobe ;
  
  
• Sur l'ancienne machine, arrêter les services réseaux (serveur web, emails, etc.) ;
  
  
• Depuis l'ancienne machine virtuelle, exécuter la commande suivante en root : dd if=/dev/vda | ssh root@<ma_nouvelle_VM> "dd of=/dev/sdb". Évidemment, attention à ne pas se tromper de disques ;
  
  
• Informer le noyau du changement de la table des partitions : partprobe ;
  
  
• Vérifier l'état des partitions (avec parted et fdisk) et des systèmes de fichiers (avec fsck) ;
  
  
• Monter les partitions. Si l'erreur « Cannot use device /dev/sdb2 which is in use (already mapped or mounted) » se produit lors d'une tentative de montage du conteneur chiffré : apt-get install udisks2: && udisksctl unlock --block-device /dev/mapper/sdb2 ; udisksctl unlock --block-device /dev/sdb2 (en root). Dans mon cas, la première commande udisksctl s'est terminée en silence et la deuxième a craché l'erreur suivante : « Error unlocking /dev/sdb2: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error unlocking /dev/sdb2: Command-line 'cryptsetup luksOpen "/dev/sdb2" "luks-2e9a6ffa-5138-4e5d-b93c-be86d6d64a49"' exited with non-zero exit status 5: Device luks-2e9a6ffa-5138-4e5d-b93c-be86d6d64a49 already exists ». Cela m'a tout de même permis de monter mon conteneur chiffré de manière habituelle : mount /dev/mapper/luks-2e9a6ffa-5138-4e5d-b93c-be86d6d64a49 /mnt/chroot ;
  
  
• Changer la configuration réseau dans /mnt/chroot/etc/network/interfaces ;
  
  
• grep -R '<anciennes_IPv4_et_v6>' /etc pour vérifier que les anciennes adresses IP ne traînent pas dans des configurations ;
  
  
• Dans mon cas, lors du redémarrage, j'ai atterri dans le grub-rescue avec l'erreur « unknown filesystem », y compris si je tente de lire mes partitions (affichées avec ls) avec ls (hd0,msdos1). En rebootant sur le mode rescue, je me suis aperçu que je n'arrivais pas à monter la première partition de mon disque, celle non chiffrée, qui contient mon /boot. D'après dumpe2fs, l'UUID de son système de fichiers ext3 ne correspond pas à l'UUID de celui de mon ancienne machine virtuelle, son dernier point de montage a été « / » et sa taille dépasse la partition. Conclusion : pour une raison que j'ignore, dd n'a pas écrasé la première partition. J'ai donc lancé la commande suivante depuis mon ancienne machine virtuelle : dd if=/dev/vda1 | ssh root@<ma_nouvelle_VM> "dd of=/dev/sdb1". Cette fois, ça chemar \o/ ;
  
  
• Dans /etc/crypttab et /etc/fstab, mon conteneur chiffré est désigné sous le nom « vda2_crypt ». Or, mon disque dur est désormais désigné sous l'appellation « sda ». J'ai peur que cela entraîne de la confusion chez moi à l'avenir, donc je décide de modifier ces deux fichiers, puis de mettre à jour mon initramfs avec update-initramfs -u -k all. Cela produit un avertissement : « cryptsetup: failed to determine cipher modules to load for /dev/mapper/sda2_crypt » ;
  
  
• Comme il s'agit d'un avertissement, je décide de passer outre et de redémarrer. Grosse erreur ! J'échoue dans un initramfs après avoir vu défiler une cascade de « /scripts/local-top/cryptroot: line 1: /sbin/cryptsetup: not found » ;
  
  
• Je redémarre sur le mode rescue de mon hébergeur. Cette fois-ci, j'ouvre mon conteneur chiffré sous l'appellation désirée : cryptsetup luksOpen /dev/sdb2 sda2_crypt. Je monte cette partition ainsi que la première partition de mon disque sur /mnt/chroot/boot, je mount -o bind /dev, /sys et /proc, je chroot, et je mets à jour mon initramfs avec update-initramfs -u -k all ;
  
  
• Cette fois-ci, le redémarrage se passe bien et je suis satisfait du résultat. \o/