URL:     https://linuxfr.org/users/rahan/journaux/une-histoire-de-backup-qui-se-termine-bien
Title:   Une histoire de backup qui se termine bien
Authors: rahan
Date:    2024-07-17T23:54:48+02:00
License: CC By-SA
Tags:    sauvegarde, restic, mailcow, pra et restauration
Score:   34


# Contexte

Depuis plus de 20 ans j'héberge moi-même mes emails. Avec les évolutions des règles anti-spams (réputation des adresses IP des FAI) et des contraintes des abonnement internet grand publique (port 25 bloqué), cet hébergement est passé de mon salon à un petit serveur dédié dans un datacenter. J'ai commencé avec une solution à base d'une Debian, puis j'ai séparé les services dans des containeurs [LXC](https://fr.wikipedia.org/wiki/LXC) pour finalement migrer vers une solution intégrée par Docker compose : [mailcow](https://mailcow.email/).

Tout cela ronronnait tranquillement depuis quelques années, je me contentais de faire des updates du système et des containers. Lors d'une de ces mises à jour, j'ai du redémarrer la machine pour passer sur un nouveau noyau (mise à jour de sécurité). Et là patatras, la machine ne redémarre pas. Un ticket chez l'hébergeur m'apprend que la machine est morte et qu'ils ne peuvent pas récupérer le disque dur (la topologie du rack empêche de retirer un disque sans éteindre toutes les machines du rack; oui, c'était du low-cost...). Seule solution : réinstallation complète sur un nouveau serveur avec récupération des données de sauvegarde.

# Réinstallation

À ma grande surprise, tout a très bien fonctionné en suivant ce plan sur une Debian :

- Suppression du paquet `bind9` (mailcow installe son propre résolveur)
- Installation des paquets  `git`, `restic`, `docker.io`, `curl`
- Installation de [docker-compose](https://github.com/docker/compose)
- Copie de la configuration de restic (`/root/backup/restic.sh`)
- Récupération du dernier snapshot restic : `restic restore abcdef01 --target /recovery`
- Il ne reste plus qu'à déplacer les deux répertoires restaurés vers `/var/lib/docker/volumes/` et `/opt/mailcow-dockerized` et à lancer les containers avec docker-compose.

Coté DNS, j'ai changé les enregistrements DNS `A` et `AAAA` du serveur défini en `MX`. Après le temps de propagation et l'expiration du ttl, j'ai commencé à recevoir les mails en attente sur les serveurs de mes correspondants.

# Les détails de la sauvegarde

Voici comment la sauvegarde des données est faite. J'utilise [restic](https://restic.net/) avec comme dépôt, un stockage dans les nuages de type [S3](https://fr.wikipedia.org/wiki/Amazon_S3) mais pas chez Amazon. Toutes les informations sont contenues dans le fichier de configuration `restic.sh` :

```bash
export AWS_ACCESS_KEY_ID=XXXXXX
export AWS_SECRET_ACCESS_KEY=YYYYYY
export AWS_DEFAULT_REGION=aa-bbb
export RESTIC_REPOSITORY=s3:www.example.com/s3
export RESTIC_PASSWORD=ZZZZZ
```

Ce fichier de configuration est critique est doit être sauvegardé et protégé. Il est en fait stocké dans mon [gestionnaire de mots de passe](https://www.passwordstore.org/).

Le script de sauvegarde est quant à lui très simple, il se contente de sauvegarder les volumes docker et les fichiers de mailcow :

```bash
#!/bin/sh
set -e
 
. ./restic.sh
 
restic backup /opt/mailcow-dockerized /var/lib/docker/volumes/
 
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 5
```

Pour s'assurer que la tache est lancée régulièrement, il faut créer les fichiers suivants (désolé, c'est du systemd):

`/etc/systemd/system/backup-restic.service` :

```systemd
[Unit]
Description=Restic backup
 
[Service]
User=root
Group=root
Type=oneshot
WorkingDirectory=/root/backup
ExecStart=/root/backup/do_backup.sh
```

`/etc/systemd/system/backup-restic.timer` :

```systemd
[Unit]
Description=Backup restic
 
[Timer]
OnCalendar=*-*-* 3:30:00
 
[Install]
WantedBy=timers.target
```

Et on n'oublie pas d'activer cette tâche : `systemctl daemon-reload && systemctl enable backup-restic.timer && systemctl start backup-restic.timer`

# Conclusions

J'ai pu valider pour la première fois mon [PRA](https://fr.wikipedia.org/wiki/Plan_de_reprise_d%27activit%C3%A9_(informatique)) en situation réelle. Le système était fonctionnel en moins de 24 heures (la panne est survenue à 23h30). Je ne pense pas avoir perdu beaucoup d'emails (mais je les avait en fait déjà lus) entre la dernière sauvegarde à 3h30 et la panne à 23h30. Je suis aussi assez content d'avoir automatisé le backup quelques semaines avant (je le lançais à la main quand j'y pensais...).

Au niveau de ce qui aurait pu être amélioré :

- Mettre à jour les enregistrements DNS beaucoup plus tôt pour pouvoir récupérer un fonctionnement nominal plus rapidement.
- Penser à lancer un backup manuel avant chaque opération à risque (redémarrage, mise à jour...)
- Avoir testé au moins une fois la procédure de reconstruction du serveur
- Mieux documenter la configuration IPv6 du serveur pour la rendre compatible avec mailcow (ajout de `net.ipv6.conf.eno1.accept_ra=2`)
- Mettre en place un backup des mails uniquement par IMAP (ceintures et bretelles)

J'espère que ce retour d'expérience pourra être utile à quelqu'un. Restic est vraiment simple à utiliser que ce soit pour la sauvegarde ou la restauration. Vu les coûts du stockage dans les nuages, il ne faut pas hésiter à mettre cela en place. Mailcow est aussi très simple à installer et déplacer le serveur s'est avéré enfantin.