Table des matières

Restauration d'une machine depuis un backup

Restauration d'une machine depuis un backup

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

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 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

# ssh -p 2242 -A backup@backup.chapril.org true

Si ce n'est pas le cas, vous pouvez suivre la section « Accès SSH » de la page 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 :

borgmatic -l

Pour avoir la synthèse du dépôt d'archive :

borgmatic -i

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.

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 :

BORG_RSH="ssh -p 2242 -A" borg info backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2021-01-02T01:43:34

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 :

BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02 etc/issue

Pour extraire l'archive entière dans le dossier courant, il faudrait faire :

BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02

Options utiles de borg extract :

          --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'

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 :

BORG_RSH="ssh -p 2242 -A" borg mount backup@backup.chapril.org:/srv/backups/$(hostname --fqdn) /mnt

Restauration de l'archive

Ajouter un hook dans le paquet backup-chapril qui dump la sortie de lsblk serait un plus.

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

vgcfgrestore -f le_fichier_backup VolumeGroupName

À 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 :

BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/$(hostname --fqdn)::2018-09-02

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.

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.

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 #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 :
```
apt update
apt install lvm2 openssh-server
```
Monter la partition root (utiliser pvscan/vgscan pour trouver les path à utiliser) :
```
vgchange -a y
mount /dev/modele-vg/root /mnt/
```

Récupérer les clés SSH depuis la partition root et démarrer sshd :

mkdir /root/.ssh
cp /mnt/etc/ssh_authorized_keys/root /root/.ssh/authorized_keys
systemctl start sshd

Se connecter en SSH
Générer une clé SSH pour l'accès aux sauvegardes :
```
ssh-keygen -t ed25519
```
Sur felicette autoriser cette clé à accéder aux sauvegardes de la VM à restaurer :
```
vi /etc/ssh/authorized_keys/backup
```

Toujours sur felicette, identifier le backup qui sera utilisé :

export BORG_REPO=/srv/backups/<SERVICE-NAME>.cluster.chapril.org/
borg list

De retour sur le SSH du livecd, tester si la connexion vers le serveur fonctionne bien :
```
ssh -p 2242 backup@backup.chapril.org true
```
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 :
```
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
```
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 :

BORG_RSH="ssh -p 2242 -A" borg extract backup@backup.chapril.org:/srv/backups/<SERVICE-NAME>.cluster.chapril.org::2021-XX-XXTXX:XX:XX

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 :

# 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

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/ :
```
ssh -L 9001:127.0.0.1:9001 root@test-backup.cluster.chapril.org
```