Sauvegarde et restauration systemd avec exemples pratiques : guide d'implémentation

Introduction

Démarrer un conteneur de production semble simple, mais l'exploitation fiable au quotidien exige une approche méthodique. Ce guide pratique montre comment aborder systemd backup et systemd restore avec des exemples concrets, comment préparer une systemd disaster recovery, planifier un systemd rollback et réaliser une systemd validation reproductible. L'objectif est pragmatique : comprendre les pièces mobiles, les tester localement, puis réduire les surprises lorsqu'on applique le même schéma en CI/CD ou dans un environnement proche de la production.

Nous relierons les concepts à des preuves concrètes : quoi configurer, quelle commande prouve que cela fonctionne, et à quoi ressemble un échec. Nous intégrerons des exemples Linux et Bash, et un service Nginx piloté par systemd. Nous montrerons aussi comment exploiter les logs (journalctl) pour inspecter et déboguer le comportement.

Vue d'ensemble du workflow

Un workflow utile pour systemd backup suit un cycle simple :

Identifier la ressource et la configuration qui l'affecte. Par exemple : unités systemd dans /etc/systemd/system, fichiers de configuration applicatifs dans /etc, et données persistantes dans /var/lib/<app>.

Définir la preuve que « ça marche ». Exemple : systemctl status <service>, systemd-analyze verify <unité>, journalctl -u <service> ou la présence d'une archive de sauvegarde horodatée.

Décrire le signal d'échec attendu. Exemple : service en état failed, messages explicites dans journalctl, ou absence d'artefacts de backup.

Documenter les hypothèses. Les chemins locaux, tags d'images Docker, noms de réseaux, fichiers d'environnement, limites de ressources et permissions varient entre un laptop, un runner CI et un hôte de production. Les rendre explicites avant de généraliser.

Exécuter de petits incréments. Configurer une chose, vérifier l'état observé, puis noter ce qui casse si la configuration manque, est erronée, ou si l'on simule un contexte proche de la production.

Points d'attention fréquents :

Différences de distribution : sur certaines distributions les unités « vendor » se trouvent sous /usr/lib/systemd/system plutôt que /lib/systemd/system.
Droits et propriétaires : un backup exécuté en root peut créer des archives difficilement restaurables par un autre compte si les permissions ne sont pas prises en compte.
Journaux persistants : sans stockage persistant, journalctl peut ne pas conserver l'historique entre redémarrages. Réglez Storage=persistent dans /etc/systemd/journald.conf si nécessaire.

Checklist pratique du workflow :

Entrée attendue (chemins, unités, données) ?
Commande/Modification (script de backup, service, timer) ?
Sortie attendue (archives, statuts, logs) ?
Signal d'échec (code retour, état failed, messages dans journalctl) ?

Plan pilote local

Nous allons bâtir un pilote local minimal autour d'un service Nginx géré par systemd, avec un script de sauvegarde, un service et un timer. Ce modèle couvre systemd backup, systemd restore, la validation et prépare la reprise après sinistre.

1) Script Bash de sauvegarde

Ce script capture : unités systemd, configuration Nginx, données (si présentes) et un extrait de logs récents.

#!/usr/bin/env bash
set -euo pipefail
TS=$(date -u +%Y%m%dT%H%M%SZ)
DEST=/var/backups/systemd/${TS}
sudo install -d -m 750 "$DEST"

# Unités locales et vendor (selon la distro)
sudo tar -C /etc/systemd/system -czf "$DEST/systemd-units.tgz" .
sudo tar -C /usr/lib/systemd/system -czf "$DEST/systemd-units-vendor.tgz" . 2>/dev/null || true

# Config Nginx et données éventuelles
sudo tar -C /etc -czf "$DEST/etc-nginx.tgz" nginx
sudo tar -C /var/lib -czf "$DEST/var-lib-nginx.tgz" nginx 2>/dev/null || true

# Logs utiles pour diagnostic
sudo journalctl --system --since "1 hour ago" > "$DEST/journal-last-hour.log"
echo "Backup OK -> $DEST"

Attendu : un dossier horodaté dans /var/backups/systemd/ contenant plusieurs archives .tgz et un fichier de logs. Échec visible : code de retour non nul, absence d'archives, messages d'erreur de permissions.

2) Service et timer systemd

Créez un service qui exécute le script, puis un timer pour l'automatiser.

/etc/systemd/system/backup-nginx.service :

[Unit]
Description=Backup Nginx et unités systemd
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/systemd-backup-nginx.sh
User=root
Group=root
Nice=10
IOSchedulingClass=best-effort
ProtectSystem=full
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

/etc/systemd/system/backup-nginx.timer :

[Unit]
Description=Timer quotidien pour backup Nginx et unités systemd

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=5m

[Install]
WantedBy=timers.target

Activez et testez :

sudo systemctl daemon-reload
sudo systemctl enable --now backup-nginx.timer
sudo systemctl start backup-nginx.service
sudo systemctl status backup-nginx.service --no-pager
systemctl list-timers | grep backup-nginx || true
journalctl -u backup-nginx.service -n 50 --no-pager

Attendu : le service s'exécute sans erreur, les archives sont créées, et le timer apparaît dans systemctl list-timers. Échec visible : état failed, erreurs de droits ou chemins introuvables dans journalctl.

3) Validation (« systemd validation »)

Schéma de validation local : exécuter manuellement le service, vérifier la présence des artefacts, et inspecter les journaux.
Vérification de configuration systemd : systemd-analyze verify /etc/systemd/system/backup-nginx.service pour repérer des directives invalides.
Preuve d'observabilité : journalctl -u backup-nginx.service retourne un historique cohérent des exécutions.

4) Restauration (« systemd restore »)

Procédure générique pour Nginx :

# 1) Stopper et rendre l'hôte cohérent
sudo systemctl stop nginx.service || true

# 2) Restaurer les unités et configs
sudo tar -C /etc/systemd/system -xzf /var/backups/systemd/<TS>/systemd-units.tgz
sudo tar -C /etc -xzf /var/backups/systemd/<TS>/etc-nginx.tgz

# 3) Recharger systemd et relancer
sudo systemctl daemon-reload
sudo systemctl enable --now nginx.service
sudo systemctl status nginx.service --no-pager

# 4) Vérifier les logs
journalctl -u nginx.service -b --no-pager | tail -n 50

Attendu : Nginx revient à l'état précédent, les unités modifiées sont prises en compte après daemon-reload. Échec visible : erreurs de permissions sur des fichiers restaurés, directives Nginx invalides, ou service en état failed.

5) Reprise après sinistre (« systemd disaster recovery »)

Scénario minimal : machine remplacée ou disque perdu.

Réinstaller l'OS et systemd.
Récupérer les archives sauvegardées (depuis un stockage externe ou distant) dans /var/backups/systemd/.
Restaurer unités et configurations comme ci-dessus.
systemd-analyze verify sur les unités critiques.
Redémarrer les services essentiels avec systemctl enable --now <service> et vérifier avec journalctl.

Pour des workloads conteneurisés (Docker), sauvegarder également les volumes associés aux données applicatives. Même si systemd n'est pas toujours utilisé à l'intérieur d'un conteneur, l'hôte qui orchestre ces services via systemd doit préserver les unités, fichiers d'environnement et points de montage.

6) Plan de rollback (« systemd rollback »)

Versionner les overrides d'unités dans /etc/systemd/system/<service>.d/override.conf et conserver les archives précédentes.
Pour revenir en arrière : restaurer l'archive antérieure, remettre l'override précédent, exécuter systemctl daemon-reload, puis systemctl restart <service>.
Vérifier immédiatement : systemctl status, journalctl -u <service>, et si besoin, systemd-analyze verify.

7) Erreurs courantes et signaux d'échec

Oublier systemctl daemon-reload après modification/restauration d'unités : les changements ne s'appliquent pas.
Sauvegarder uniquement /etc/systemd/system et ignorer les unités « vendor » sous /usr/lib/systemd/system : restauration incomplète.
Négliger les fichiers d'environnement (souvent dans /etc/default ou /etc/sysconfig) : service qui démarre sans variables critiques.
Permissions incohérentes après extraction d'archives : échecs au démarrage. Vérifier propriétaires et modes.
Journaux volatils : perte d'historique au redémarrage. Envisager un stockage persistant pour journald.
Dans Docker, supposer que systemd tourne à l'intérieur du conteneur : souvent faux. Gérer les sauvegardes au niveau des volumes et de l'hôte.

Conclusion

La combinaison de petits exemples testables, de preuves locales claires et de signaux d'échec rend systemd backup et systemd restore fiables. Avant d'automatiser, validez chaque étape en local : unités, scripts, timers, journaux et archives. Un plan de systemd disaster recovery gagne en robustesse si les hypothèses sont explicites et si la systemd validation (statuts, verify, logs) est intégrée dès le pilote local. Préparez également le systemd rollback avec des archives versionnées et des overrides traçables.

Étape suivante : choisissez un service (par exemple Nginx), écrivez précisément les commandes pour le construire, le lancer, l'inspecter, l'arrêter et le recréer. Comparez le résultat avec vos pratiques Linux, Bash et Docker afin que l'implémentation s'inscrive dans un modèle d'exploitation cohérent. Un bon workflow rend les défaillances visibles : journaux accessibles, données persistantes qui survivent aux reconstructions, et un comportement local suffisamment proche de la production pour détecter tôt les erreurs.