Sauvegardes automatisées avec BorgBackup : déduplication, stockage distant et contrôles de RESTauration

Dans cet article, j’explique comment mettre en place de manière techniquement fiable des Sauvegardes automatisées avec BorgBackup : de l’architecture des Repository et du stockage dédupliqué au transport distant, en passant par les contrôles de RESTauration automatisés, les stratégies de prune et les étapes typiques de dépannage. L’objectif est d’établir des procédures opérationnelles sûres pour les administrateurs, les System Engineers et les exploitants, axées sur la disponibilité, l’intégrité et la maintenabilité.

Pourquoi BorgBackup ? Un bref aperçu de l’architecture

BorgBackup (ou simplement Borg) est un outil de sauvegarde au niveau des fichiers qui offre la déduplication basée sur le contenu, le chiffrement de bout en bout optionnel et un transfert efficace via SSH. La déduplication signifie que des segments de données identiques (chunks) ne sont stockés qu’une seule fois dans le Repository ; cela réduit fortement l’espace disque pour des sauvegardes répétées. Borg stocke les sauvegardes dans un Repository, qui peut résider localement sur un serveur ou être accédé à distance via SSH avec borg serve. La topologie du Repository est déterminante pour la performance, le verrouillage et la maintenance ; elle doit donc être planifiée tôt.

Sauvegardes automatisées avec BorgBackup : architecture et règles d’exploitation

Pour un fonctionnement en production, plusieurs aspects sont impératifs :

• Séparation par client ou par service : créez un Repository distinct pour chaque client ou service critique lorsque les règles de rétention ou le contrôle d’accès diffèrent.
• Compatibilité des versions : maintenez les versions Borg client et serveur synchronisées ; testez les changements de version en environnement de staging avant de les déployer en production.
• Sécurité SSH : utilisez une authentification par clé, un compte de sauvegarde dédié (par ex. backup-user) et la RESTriction de commande AuthorizedKeys pour limiter l’accès SSH à borg serve.
• Planification des ressources : les sauvegardes initiales sollicitent fortement le CPU et les E/S ; prévoyez une augmentation de la mémoire et du CPU sur les clients et, si nécessaire, des pics de charge sur l’hôte du Repository.

Initialisation du Repository, stratégies de chiffrement et gestion des clés

Borg prend en charge des modes de chiffrement tels que repokey (clé dans le Repository, protégée par une passphrase) et keyfile (clé privée externe). Repokey est opérationnellement plus simple, tandis que le keyfile impose une gestion stricte des clés, car la clé privée est conservée séparément. La perte de la clé pour des dépôts chiffrés entraîne généralement une perte de données définitive ; planifiez donc des processus de rotation des clés, de sauvegarde des clés et de rétention.

# Repository lokal initialisieren (repokey)
borg init --encryption=repokey /srv/backup/repo

# Remote-Repository-Init per SSH (auf Backup-Host)
ssh backup-admin@backup.example.com "borg init --encryption=repokey /srv/backup/repo"

Une entrée AuthorizedKeys sécurisée avec RESTriction empêche l’accès shell interactif et n’autorise que les opérations Borg pour le Repository indiqué :

command="/usr/bin/borg serve --RESTrict-to-path /srv/backup/repo",no-agent-forwarding,no-port-forwarding,no-pty ssh-rsa AAAA... backup-client@example

Gérez les clés SSH et les passphrases dans un coffre de secrets dédié (par ex. HashiCorp Vault) et sauvegardez les clés selon des politiques définies vers un emplacement séparé et hors ligne. La documentation et une rotation régulière des clés sont des éléments opérationnels essentiels.

Flux de sauvegarde pratique et scripts robustes

Les sauvegardes doivent être idempotentes, atomiques et correctement journalisées. Utilisez un script wrapper avec set -euo pipefail, un verrouillage (p. ex. flock), une sortie structurée pour le parsing du monitoring et la gestion des codes de sortie.

#!/usr/bin/env bash
set -euo pipefail

LOCKFILE=/var/lock/borg-backup.lock
exec 9>&1

flock -n 9 || { echo "Backup läuft bereits"; exit 2; }

export BORG_REPO=ssh://backup-user@backup.example.com:22/srv/backup/repo
export BORG_PASSPHRASE_FILE=/etc/borg/passphrase
export BORG_RSH="ssh -i /etc/borg/backup_key -o StrictHostKeyChecking=yes"

LOGFILE=/var/log/borg-backup/$(date +%F).log
mkdir -p $(dirname "$LOGFILE")

/usr/bin/borg create -v --stats --compression zstd,6 
  $BORG_REPO::"$(hostname)-$(date +%Y-%m-%d_%H:%M:%S)" 
  /etc /var/www /srv/data 
  --exclude '/var/cache' --exclude '/proc' --exclude '/sys' 2>&1 | tee -a "$LOGFILE"

exit_code=${PIPESTATUS[0]}

if [ "$exit_code" -ne 0 ]; then
  echo "Borg create failed with exit $exit_code" | tee -a "$LOGFILE"
  exit $exit_code
fi

# Prune nur nach erfolgreichem Backup
/usr/bin/borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1 2>&1 | tee -a "$LOGFILE"

Exécutez ce script via systemd-timer, pas via cron, pour obtenir un meilleur comportement au démarrage, des politiques de retry automatiques et une connexion native des logs à journalctl.

Exemple : service systemd et timer

# /etc/systemd/system/borg-backup.service
[Unit]
Description=Borg Backup Job
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/run-borg-backup.sh
Nice=10

# /etc/systemd/system/borg-backup.timer
[Unit]
Description=Daily Borg Backup Timer

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Réglez Nice et l’affinité CPU, si nécessaire, pour décharger les tâches de sauvegarde par rapport aux services de production.

Déduplication : principe de fonctionnement et conséquences opérationnelles

Borg utilise le content-defined chunking : les données sont découpées en blocs variables identifiés par un hash cryptographique. La déduplication économise de l’espace, mais comporte des implications :

• La déduplication est appliquée au niveau du repository : les gains ne se produisent que dans le même repository, pas entre plusieurs repos.
• Le chunking entraîne une charge CPU et parfois mémoire vive ; les clients avec beaucoup de petits fichiers en bénéficient particulièrement, mais la création des chunks sollicite les ressources.
• Lors de la RESTauration de grandes quantités de données, de nombreuses petites lectures sont effectuées ; planifiez les profils I/O et testez les fenêtres de RESTauration.

Remote-Storage-Optionen: Bewertung und Empfehlungen

Le repository SSH (borg serve) est l’option recommandée : chemins de code testés, gestion correcte des locks et faible complexité. Les backends alternatifs comportent des risques :

• NFS/SMB : peuvent provoquer des problèmes de verrouillage et de cohérence et favoriser la corruption du repository ; les systèmes de fichiers réseau montés ne sont donc pas recommandés.
• Stockage d’objets (p. ex. S3) : Borg ne prend pas en charge S3 nativement ; des passerelles (SFTP ou bridges système de fichiers) sont possibles, mais augmentent la complexité et doivent être évaluées sur l’intégrité, la latence et les performances.

Recommandations matérielles pour le repository

Pour les repositories avec une forte charge de RESTauration ou d’écriture, les backends basés sur SSD sont avantageux, car ils traitent plus efficacement de nombreux petits I/Os. Pour l’archivage à long terme pur, des baies HDD économiques avec RAID/Erasure-Coding peuvent être utilisées, à condition de prévoir des tests de RESTauration et une bande passante suffisante.

Stratégies de rétention, planification du prune et impacts

La rétention doit mettre en balance les points de RESTauration (RPO) et les coûts de stockage. Pratiques éprouvées :

• Conservation à court terme : snapshots quotidiens (p. ex. 7 jours)
• Moyen terme : snapshots hebdomadaires et mensuels
• Long terme : archives annuelles pour la conformité

# Prune dry-run zur Überprüfung
borg prune -v --list $BORG_REPO --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=1 --dry-run

Prune entfernt nur Archive; durch Deduplizierung werden Chunks physisch gelöscht, sobald sie von keinem verbleibenden Archiv mehr referenziert werden. Führen Sie regelmäßige Dry-Runs durch und dokumentieren Sie, welche RESTore-Punkte verloren gingen, um SLA-Konformität sicherzustellen.

Contrôles automatisés de RESTauration et workflows de validation

Une sauvegarde n’est aussi bonne que sa RESTauration. Deux niveaux de vérification sont pragmatiques :

1. Intégrité du repository : borg check --repository-only régulièrement ; périodiquement borg check --verify-data durant les fenêtres de maintenance, car cette dernière commande est intensive en IO.
2. Test de RESTauration fonctionnel : extraire des artefacts critiques (p. ex. configurations, dumps de bases de données) vers un environnement de test et valider par des sommes de contrôle, des tests d’import de bases de données ou le démarrage des services dans un environnement isolé.

# RESTore-Validierung: Beispiel für nginx-Konfiguration
set -euo pipefail
TMPDIR=$(mktemp -d /tmp/borg-RESTore-test-XXXX)
trap 'rm -rf "$TMPDIR"' EXIT

ARCHIVE=$(borg list --short $BORG_REPO | tail -n1)

borg extract $BORG_REPO::"$ARCHIVE" etc/nginx/nginx.conf --target "$TMPDIR"
sha256sum "$TMPDIR/etc/nginx/nginx.conf" | awk '{print $1}' > /tmp/RESTore-check-actual
# Vergleichen Sie die resultierende Prüfsumme mit einer erwarteten Prüfsumme

Les contrôles de RESTauration automatisés doivent déclencher des alertes orientées résultats (mail/ChatOps/événement de monitoring) et s’exécuter au moins hebdomadairement pour les artefacts critiques. Utilisez des hôtes de test ou des conteneurs pour isoler, afin que la validation n’altère pas les données de production.

Supervision, parsing des sorties et alertes

Collectez ces métriques pour l’observabilité : dernière exécution réussie, durée, volume de données transférées, nombre d’octets dédupliqués, résultats du prune et codes de sortie Borg. Développez un parser robuste qui tient compte des différences de texte liées aux locales.

# Beispiel: sehr simples Parsing (nur Ausgangspunkt)
transferred_bytes=$(grep "Transferred" $LOGFILE | awk '{print $2}')
processed_files=$(grep "Number of files" $LOGFILE | awk -F: '{print $2}' | tr -d ' ')

# Senden an Monitoring (pseudo)
# curl -X POST http://monitoring.example.local/metrics -d "borg_transferred_bytes=$transferred_bytes"

Pour les environnements de production, optez pour un exporter ou connecteur dédié qui génère des logs structurés (JSON) ou envoie les métriques directement à Prometheus/Grafana. Testez le parser avec différentes versions de Borg.

Cas d’erreur typiques et séquence de vérification rapide

En cas d’erreurs de sauvegarde, suivez une séquence de vérification standardisée, à documenter dans le runbook d’incident :

1. Vérifier la connexion SSH :
   ShellCode kopieren

   ssh -vvv backup-user@backup.example.com

   — affiche des erreurs de clé et d’authentification.

2. Vérifier l’espace disque sur l’hôte du dépôt :
   ShellCode kopieren

   ssh backup@backup.example.com df -h /srv/backup

3. Vérifier l’état du repository :
   ShellCode kopieren

   borg list $BORG_REPO
   borg info $BORG_REPO::ARCHIVNAME

4. Problèmes de verrouillage :

borg break-lock $BORG_REPO

— uniquement après analyse et si aucun processus Borg n’est actif.

borg check --repository-only $BORG_REPO

Évitez les tentatives de réparation hâtives telles que borg check --repair sans sauvegarde préalable des métadonnées du repository ; documentez chaque étape.

Stratégie de migration et d’urgence

Pour les migrations ou les situations d’urgence, des mesures claires sont recommandées :

1. Sauvegardez les métadonnées du repository et créez un snapshot du système de fichiers de l’hôte de sauvegarde (p. ex. snapshot LVM ou ZFS).
2. Effectuez un test de RESTauration sur un hôte séparé et validez les charges de travail critiques.
3. En cas de corruption du repository : d’abord borg check --repository-only, documenter, contacter la communauté ou le support, puis planifier des actions de réparation ciblées.

Préparez une stratégie de repli : si une mise à niveau de version de Borg échoue, vous devez pouvoir revenir à la version précédente de Borg et poursuivre avec un snapshot du système de fichiers du repository.

Optimisation des performances & intégration au système de fichiers

Optimisations éprouvées en pratique :

• Level de compression: --compression zstd,6 est un bon compromis entre charge CPU et taille ; des niveaux plus élevés économisent de l’espace mais augmentent l’utilisation CPU.
• Caches de listes de fichiers: Borg peut utiliser des caches de liste de fichiers ; testez BORG_FILES_CACHE pour des systèmes de fichiers très volumineux.
• Snapshots pour la cohérence: pour les bases de données, utilisez des snapshots de stockage (LVM, ZFS) ou des dumps cohérents (p. ex. pg_dump) avant l’exécution de Borg, car Borg est un outil au niveau fichier.

Maintenance du repository: compact, upgrade et changement de version

Une maintenance régulière aide à limiter le nombre de fichiers de segments et à préserver les performances. Utilisez :

# Repository komprimieren/neu packen
borg compact $BORG_REPO

# Vor einem Versionswechsel: Backup aller Repository-Metadaten und Tests in Staging
borg upgrade --help  # prüfen, wenn Versionswechsel nötig ist

Effectuez la maintenance du repository pendant des fenêtres de maintenance et testez l’effet sur la durée de RESTauration et la charge I/O.

Liste de contrôle des bonnes pratiques pour l’exploitation

• Contrôles de RESTauration automatisés et réguliers (p. ex. hebdomadaires pour les fichiers critiques)
• Séparation des hôtes de sauvegarde et de production ; durcissement SSH pour les utilisateurs de sauvegarde
• Documenter la stratégie de prune ; effectuer régulièrement des dry runs de prune
• Monitoring basé sur les codes de sortie et journalisation structurée
• Gestion sécurisée des clés : sauvegarde et rotation des passphrases/fichiers de clés
• Tests en staging pour les mises à niveau de version de Borg et la maintenance du repository
• Runbooks d’incident documentés avec des séquences de vérification claires

Conclusion

BorgBackup est une solution éprouvée pour des sauvegardes automatisées et dédupliquées, à condition que la topologie du repository, la sécurité SSH, le chiffrement et la validation des RESTaurations soient planifiés de manière rigoureuse. Essentiels : contrôles de RESTauration automatisés, un processus de prune vérifiable et le monitoring des résultats des tâches. La déduplication réduit sensiblement les besoins en stockage et en bande passante, mais exige une attention particulière à la planification des ressources et à la gestion des clés. Avec des runbooks clairs, des tests réguliers et un workflow de monitoring strict, vous obtenez une stratégie de sauvegarde robuste qui soutient de manière fiable l’exploitation et la RESTauration.

Si vous avez besoin d’un plan d’implémentation concret ou d’un audit pour votre topologie de sauvegarde, vous pouvez en dériver un runbook opérationnel fiable qui couvre à la fois les exigences de stockage et de RESTauration.

Sauvegardes automatisées avec BorgBackup : géorédondance, audit et attributs de fichiers

En complément de la planification de routine, vous devriez prendre en compte explicitement trois domaines pratiques : le stockage géorédondant, la traçabilité des accès et le traitement des attributs de fichiers/ACL. Ces points impactent directement la RESTaurabilité, la conformité et la gestion des incidents.

Géorédondance et modèles de réplication

Borg n’offre pas de réplication multi-site intégrée. Les modèles éprouvés sont :

• Push séquentiel : écrivez la sauvegarde successivement dans deux dépôts (local → Remote A → Remote B). Avantage : logique simple ; inconvénient : durée totale plus longue.
• Réplication au niveau stockage : utilisez ZFS-Send/Receive, la réplication de blocs ou la réplication d’object store en dessous du système de fichiers pour produire des répliques atomiques. Avantage : copies cohérentes ; inconvénient : complexité d’infrastructure accrue.
• Snapshots comme point de transfert : créez un snapshot de stockage cohérent (LVM/ZFS) et répliquez-le vers le site secondaire, au lieu de copier des fichiers individuels du dépôt.

Veillez à inclure la gestion des locks, des vérifications de cohérence et la planification de la bande passante. La réplication sans vérification d’intégrité peut multiplier la corruption.

Audit, contrôle d’accès et traçabilité

RESTreignez l’accès SSH via AuthorizedKeys-Command, consignez centralement toutes les opérations Borg (journal/syslog → SIEM) et instrumentez le compte de sauvegarde avec des règles d’audit (auditd) pour les événements fichier et processus. Ainsi, vous détecterez des exportations ou RESTaurations non autorisées et pourrez reconstituer les horaires d’accès ainsi que les responsables.

Attributs de fichiers, ACLs et SELinux‑contextes

Vérifiez si vos sauvegardes doivent inclure les attributs étendus, les POSIX‑ACLs et les SELinux‑contextes (fichiers de configuration, répertoires home). Activez les options d’archivage appropriées et validez lors de la RESTauration que les droits et contextes sont préservés ; c’est crucial pour les redémarrages en production.

Runbook d’urgence rapide (résumé)

1. Assurer la disponibilité : basculer le DNS/load balancer vers l’hôte de RESTauration.
2. Contrôle rapide : exécuter borg list / borg info sur le dépôt secondaire.
3. Vérification d’intégrité : borg check –repository-only.
4. RESTauration de basculement : extraire et valider en priorité les configurations critiques.
5. Audit et documentation : consigner toutes les étapes, faire pivoter les clés en cas de compromission.

Ces mesures comblent l’écart entre « la sauvegarde fonctionne » et « nous pouvons redémarrer en production après une catastrophe » et devraient faire partie de votre runbook opérationnel.

Les Backup-Prune sont également importants pour ce thème. L’article situe clairement ces aspects et indique ce qui compte au quotidien.