====== Restauration d'une machine depuis un backup ======

<note warning>On est ici dans une documentation a l'aveugle d'un truc un peu touchy, donc il est possible que des erreurs subsistent.</note>

  * La logique de sauvegarde est en mode push. Par réciprocité on va envisager la restauration en mode pull.
  * Il n'y a pas qu'une manière de faire.

On propose depuis n'importe qu'elle machine du cluster :

  - d'établir la connectivité ssh
  - de voir comment téléchager les fichiers de la machine
  - de lister les taches à faire pour restaurer l'archive

===== Connectivité SSH =====

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
<code bash>
# ssh -p 2242 -A backup@backup.chapril.org true
</code>

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.

===== Infos sur le dépôt =====

Pour lister les backups (archives) d'une VM, exécuter depuis cette VM :

<code bash>
borgmatic -l
</code>

Pour avoir la synthèse du dépôt d'archive :
<code bash>
borgmatic -i
</code>

<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)::2021-01-02T01:43:34
</code>

Pour extraire /etc/issue de l'archive précédente dans le dossier courant, on liste le fichier de façon relative, comme un tar :
<code bash>
BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02 etc/issue
</code>

Pour extraire l'archive entière dans le dossier courant, il faudrait faire :
<code bash>
BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02
</code>

Options utiles de borg extract :
<code bash>
          --list                           output verbose list of items (files, dirs, ...)
          -n, --dry-run                    do not actually change any files
          -e PATTERN, --exclude PATTERN    exclude paths matching PATTERN

          # Extract entire archive
          $ borg extract /path/to/repo::my-files

          # Extract entire archive and list files while processing
          $ borg extract -v --list /path/to/repo::my-files

          # Extract the "src" directory
          $ borg extract /path/to/repo::my-files home/USERNAME/src

          # Extract the "src" directory but exclude object files
          $ borg extract /path/to/repo::my-files home/USERNAME/src --exclude '*.o'
</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 =====

<note tip>Ajouter un hook dans le paquet ''backup-chapril'' qui dump la sortie de ''lsblk'' serait un plus.</note>

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
</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 :
<code bash>
BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02
</code>

Ensuite il reste à

  * installer un bootloader
  * 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>[[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>