Différences

Ci-dessous, les différences entre deux révisions de la page.

--- admin:procedures:restaurer_machine [2018/10/04 20:20] – fpoulain
+++ admin:procedures:restaurer_machine [2023/07/17 21:30] (Version actuelle) – correction du switch pour obtenir les infos pilou
@@ Ligne 14: / Ligne 14: @@
 ===== Connectivité SSH =====
-Le pool de backup est sur la VM icinga2 (nommée ainsi car elle sert également de relais d'exécution Icinga pour tester les services avec une regard extérieur), qui est un KVM porté par galanga.april.org. Elle est accessible à l'adresse backup.chapril.org.
+Le pool de backup est sur la [[admin:machines_virtuelles:felicette|VM felicette]], qui est un KVM porté par galanga.april.org. Elle est accessible à l'adresse backup.chapril.org.
 Vous devez être capable d'exécuter avec succès
@@ Ligne 23: / Ligne 23: @@
 Si ce n'est pas le cas, vous pouvez suivre la section « Accès SSH » de la page [[admin:procedures:sauvegarder_machines#acces_ssh]], en prenant soin de ne pas vous restreindre à une commande forcée qui risque de vous handicaper.
-===== Télécharger un tarball de la VM =====
+===== Infos sur le dépôt =====
-Pour lister les backups d'une VM :
+Pour lister les backups (archives) d'une VM, exécuter depuis cette VM :
 <code bash>
-BORG_RSH="ssh -p 2242 -A" borg list backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)
+borgmatic -l
 </code>
-en adaptant le hostname, par exemple :
+Pour avoir la synthèse du dépôt d'archive :
 <code bash>
-BORG_RSH="ssh -p 2242 -A" borg list backup@backup.chapril.org:/srv/backups/admin.cluster.chapril.org
+borgmatic -i
 </code>
-En supposant que ''2018-09-02'' soit le nom d'un backup, pour voir les infos d'un backup particulier :
+<note tip>C'est est tout pour le moment. La version Buster de borgmatic est vieille et donc ne prend malheureusement pas bien en charge la restauration. On passe à borg.</note>
+===== Télécharger un tarball de la VM =====
+En supposant que ''2021-01-02T01:43:34'' soit le nom d'une archive, pour voir les infos d'une archive en particulier :
 <code bash>
-BORG_RSH="ssh -p 2242 -A" borg info backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02
+BORG_RSH="ssh -p 2242 -A" borg info backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2021-01-02T01:43:34
 </code>
@@ Ligne 69: / Ligne 74: @@
 </code>
+===== Monter le dépôt de la VM =====
+Avant de restaurer il est parfois utile d'inspecter en détails une archive ou un dépot entier à l'aide d'un point de montage. On peut le monter localement :
+<code>
+BORG_RSH="ssh -p 2242 -A" borg mount backup@backup.chapril.org:/srv/backups/$(hostname --fqdn) /mnt
+</code>
 ===== Restauration de l'archive =====
@@ Ligne 75: / Ligne 87: @@
 Il faut avoir un fs près à recevoir les fichiers. Pour reconstruire le lvm à l'identique, le dossier /etc/lvm/backup/ est probablement utile, le /etc/fstab aussi. Si vous avez un volume vierge sous la patte vous pouvez restaurer la structure LVM à l'aire de
 <code>
-vgcfgrestore -f le_fichier_backup VolumeGroupName.
+vgcfgrestore -f le_fichier_backup VolumeGroupName
 </code>
+À défaut de tout autre chose, on peut imaginer cloner la « VM modèle », adapter les tailles de LVM et surtout des LVs, et monter les FS de l'image QCOW via les ''libguestfs-tools'' depuis n'importe quelle hôte.
 On se met à l'emplacement de la future racine :
@@ Ligne 86: / Ligne 100: @@
   * installer un bootloader
-  * restaurer les dumps engendrés par /etc/borg/scripts/*hooks
+  * restaurer les dumps engendrés par /etc/borg/scripts/*hooks (restauration SQL et ''dpkg --set-selections'')
+  * vérifier la configuration réseau / bail dhcp, surtout si la mac a changé
   * penser à tout ce qu'on a oublié
 Et ça devrait rouler.
-<note tip>L'expérience montre que couper le ''cron'' est une bonne pratique. Il ne suffit pas de regarder ''/etc/cron.d'', ça peut être bien plus sioux.</note>
+<note tip>[[https://admin.april.org/doku.php?id=sysadm:reconstruction_d_une_vm | L'expérience ]] montre que couper le ''cron'' est une bonne pratique. Il ne suffit pas de regarder ''/etc/cron.d'' : la configuration totale de ''cron'' peut être bien plus sioux.</note>
+===== Exemple de procédure =====
+Ceci est un exemple de procédure appliquée pour faire un test de restauration de la VM //pad// dans le cadre du ticket de test de reprise [[https://agir.april.org/issues/2408|#2408]].
+Il est basé sur les éléments ci-dessus mais j'ai utilisé un LiveCD plutôt que de monter les qcow sur l'hôte.
+  - Cloner la VM //modèle//
+  - Sur la VM crée, configurer la même adresse mac que la machine à restaurer. Dans le cas d'un test de restauration, suivre la procédure de création de VM pour faire la config réseau.
+  - Démarrer la VM et mettre à jour
+  - Modifier la configuration de la VM pour qu'elle démarre sur un livecd Debian. Il faut arrêter la VM et pas seulement redémarrer pour que cette modif soit prise en compte
+  - Une fois sur le livecd, installer les outils nécessaires et configurer un serveur SSH : <code bash>
+apt update
+apt install lvm2 openssh-server
+</code>
+   - Monter la partition root (utiliser pvscan/vgscan pour trouver les path à utiliser) : <code bash>
+vgchange -a y
+mount /dev/modele-vg/root /mnt/
+</code>
+   - Récupérer les clés SSH depuis la partition root et démarrer sshd : <code bash>
+mkdir /root/.ssh
+cp /mnt/etc/ssh_authorized_keys/root /root/.ssh/authorized_keys
+systemctl start sshd
+</code>
+  - Se connecter en SSH
+  - Générer une clé SSH pour l'accès aux sauvegardes : <code bash>
+ssh-keygen -t ed25519
+</code>
+  - Sur felicette autoriser cette clé à accéder aux sauvegardes de la VM à restaurer : <code bash>
+vi /etc/ssh/authorized_keys/backup
+</code>
+  - Toujours sur felicette, identifier le backup qui sera utilisé : <code bash>
+export BORG_REPO=/srv/backups/<SERVICE-NAME>.cluster.chapril.org/
+borg list
+</code>
+  - De retour sur le SSH du livecd, tester si la connexion vers le serveur fonctionne bien : <code bash>
+ssh -p 2242 backup@backup.chapril.org true
+</code>
+  - Récupérer le fichier _/etc/fstab_ pour identifier comment le serveur était partitionné. Se poser la question de savoir s'il faut repartionner de façon identique : <code bash>
+BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/<SERVICE-NAME>.cluster.chapril.org::2021-XX-XXTXX:XX:XX etc/fstab
+</code>
+  - Procéder au partitionnement et monter les partitions dans en suivant la bonne arborescence, dans /mnt par exemple
+  - Procéder à la récupération des fichiers, il faut se cd dans le dossier puis exécuter la commande, par exemple : <code bash>
+BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/<SERVICE-NAME>.cluster.chapril.org::2021-XX-XXTXX:XX:XX
+</code>
+  - S'il sagit d'un test de restauration, s'assurer qu'il ne reste pas de traces de l'ancienne IP dans la configuration. Par exemple dans ''/etc/firehol/firehol.conf''
+  - Redémarrer la VM sur son disque
+  - S'il y a une base de données, il faudra la restaurer, par exemple pour pad : <code bash>
+# Recréer le cluster (fichiers vides à la restauration) :
+pg_lsclusters
+pg_dropcluster --stop 11 main
+pg_createcluster --start 11 main
+systemctl restart postgresql@11-main.service
+# Restaurer les fichiers SQL
+mv /var/backups/pgsql/*.sql.bz2 /usr/lib/postgresql/
+su - postgres
+bzip2 -c -d postgres.sql.bz2 | psql postgres
+bzip2 -c -d template1.sql.bz2 | psql template1
+createdb etherpad
+createuser etherpad
+bzip2 -c -d etherpad.sql.bz2 | psql etherpad
+rm etherpad.sql.bz2 postgres.sql.bz2 template1.sql.bz2
+</code>
+  - Pour un test de restauration, il est possible d'utiliser ssh pour faire un tunnel et tester le service. Par exemple pour pad, l'application est alors accessible sur http://127.0.0.1:9001/ : <code bash>
+ssh -L 9001:127.0.0.1:9001 root@test-backup.cluster.chapril.org
+</code>