Sauvegarde et restauration¶

Ce qu'il faut sauvegarder dépend de votre modèle d'hébergement.

Modèle	Données du domaine	Configuration locale des agents
Cloud du projet	Sauvegardées par le projet	À votre charge
Auto-hébergé	À votre charge	À votre charge

Sauvegarder la configuration locale des agents¶

C'est la partie la plus vite oubliée, et la plus pénible à refaire à la main.

sudo tar czf /var/backups/abls-etc-$(hostname)-$(date +%F).tar.gz /etc/abls/

Cette archive contient le domain_secret

Chiffrez-la ou stockez-la sur un support protégé. Toute personne qui l'obtient peut s'authentifier auprès de l'API au nom de votre domaine.

sudo tar czf - /etc/abls/ | gpg -c > /var/backups/abls-etc-$(date +%F).tar.gz.gpg

Notez également, en clair et à part, la liste des server_uuid de vos machines :

sudo grep -h server_uuid /etc/abls/*.conf

Sans eux, une réinstallation crée de nouveaux serveurs côté API et impose de re-rattacher les agents dans la Console.

Sauvegarder la base de données (socle auto-hébergé)¶

sudo mariadb-dump --all-databases --single-transaction --routines --events \
  | gzip > /var/backups/abls-db-$(date +%F).sql.gz

--single-transaction permet une sauvegarde cohérente sans bloquer l'API.

Séparer configuration et archives¶

Les archives représentent l'essentiel du volume mais ont une valeur bien moindre. Si vous manquez de place, sauvegardez les deux à des fréquences différentes :

# Configuration : quotidienne, à conserver longtemps
sudo mariadb-dump --databases <bases_de_configuration> --single-transaction \
  | gzip > /var/backups/abls-conf-$(date +%F).sql.gz

# Archives : hebdomadaire, rotation courte
sudo mariadb-dump --databases <bases_d_archives> --single-transaction \
  | gzip > /var/backups/abls-arch-$(date +%F).sql.gz

Sauvegarder les interfaces web¶

Console et Home sont des clones Git : rien à sauvegarder sauf les fichiers que vous avez personnalisés.

sudo tar czf /var/backups/abls-web-$(date +%F).tar.gz \
  /var/www/html/abls-console/public/js/config.js \
  /etc/httpd/conf.d/abls-*.conf

Danger

Le VirtualHost de Home contient OIDCClientSecret et OIDCCryptoPassphrase. Même précaution de chiffrement que pour /etc/abls/.

Automatiser¶

# /etc/cron.daily/abls-backup
#!/bin/sh
set -e
DEST=/var/backups
DATE=$(date +%F)

tar czf - /etc/abls/ | gpg --batch --yes -c --passphrase-file /root/.abls-backup-pass \
  > "$DEST/abls-etc-$DATE.tar.gz.gpg"

mariadb-dump --all-databases --single-transaction --routines --events \
  | gzip > "$DEST/abls-db-$DATE.sql.gz"

find "$DEST" -name 'abls-*' -mtime +30 -delete

sudo chmod 0700 /etc/cron.daily/abls-backup
sudo chmod 0400 /root/.abls-backup-pass

Une sauvegarde locale n'est pas une sauvegarde

Recopiez les archives sur un autre support ou une autre machine. Un disque qui lâche emporte la production et ses sauvegardes.

Restaurer un agent¶

Réinstaller le système et le paquet de l'agent ;
déclarer les dépôts et installer le paquet ;
restaurer /etc/abls/ :

sudo tar xzf /var/backups/abls-etc-2026-09-30.tar.gz -C /
sudo chown -R root:abls /etc/abls
sudo chmod 0640 /etc/abls/*.conf

réactiver les services.

L'agent se réenrôle seul et retrouve son identité, à condition que le server_uuid et le agent_tech_id soient ceux d'origine.

Restaurer la base de données¶

sudo systemctl stop abls-habitat-api.service
zcat /var/backups/abls-db-2026-09-30.sql.gz | sudo mariadb
sudo systemctl start abls-habitat-api.service

Cohérence de version

Restaurez une sauvegarde dans une API de même version ou plus récente. Une API plus ancienne ne saura pas lire un schéma déjà migré.

Tester la restauration¶

Une sauvegarde non testée n'a aucune valeur. Au moins une fois par an :

[ ] Restaurer la base sur une instance de test
[ ] Démarrer une API de test pointant dessus
[ ] Vérifier que les domaines, les modules D.L.S et les synoptiques sont présents
[ ] Restaurer /etc/abls/ sur une machine de test et vérifier l'enrôlement
[ ] Mesurer la durée réelle de la restauration, pour connaître votre temps de reprise