Sauvegardes automatisées avec BorgBackup : protéger une infrastructure auto-hébergée

You are currently viewing Sauvegardes automatisées avec BorgBackup : protéger une infrastructure auto-hébergée

Sauvegardes automatisées avec BorgBackup : protéger une infrastructure auto-hébergée

Sauvegardes automatisées avec BorgBackup : protéger une infrastructure auto-hébergée

Déduplication, chiffrement et rétention : mettre en place une stratégie de backup fiable pour des services comme CKAN, Nextcloud, Gitea et PostgreSQL.

Le backup, parent pauvre de l’auto-hébergement

Quand on auto-héberge une dizaine de services — portail de données, forge Git, cloud collaboratif, base de données — on investit naturellement dans le déploiement, le monitoring, la CI/CD. Les sauvegardes, elles, arrivent souvent en dernier. Un script pg_dump lancé par cron, un tar copié manuellement sur un disque externe, parfois rien du tout. Jusqu’au jour où un disque lâche, une mise à jour corrompt une base, ou un ransomware chiffre le serveur.

Une stratégie de sauvegarde sérieuse repose sur trois piliers : l’automatisation (pas d’intervention humaine requise), la vérification (un backup non testé n’existe pas), et la rétention (pouvoir remonter dans le temps). BorgBackup coche ces trois cases avec élégance.

Pourquoi BorgBackup

BorgBackup (ou Borg) est un outil de sauvegarde open source qui se distingue par sa déduplication au niveau des blocs. Concrètement, si vous sauvegardez 50 Go de données et que seuls 200 Mo ont changé depuis la dernière sauvegarde, Borg ne stocke que ces 200 Mo. Le gain en espace disque et en bande passante est considérable, surtout pour des volumes de données importants comme ceux d’un portail CKAN ou d’une instance Nextcloud.

Ses atouts principaux sont la déduplication par blocs de taille variable (bien plus efficace qu’une déduplication par fichier), le chiffrement côté client avec AES-256 (vos données sont illisibles sur le serveur de stockage distant), la compression configurable (LZ4, ZSTD, LZMA), et une gestion fine de la rétention avec des politiques temporelles.

Architecture typique

Dans une infrastructure auto-hébergée, l’architecture de sauvegarde avec Borg suit généralement ce schéma :

  • Serveur de production : exécute les services (Docker, PostgreSQL, volumes). Un script déclenché par cron ou systemd timer prépare les données (dumps SQL, exports) puis lance borg create.
  • Dépôt Borg local : un volume dédié sur le même serveur pour les restaurations rapides. Utile en cas de suppression accidentelle, mais insuffisant en cas de panne matérielle.
  • Dépôt Borg distant : un second serveur (ou un service de stockage compatible SSH) reçoit les archives via borg create avec un dépôt distant (ssh://backup-server/repo). C’est la protection contre la perte du serveur principal.

La règle d’or reste le principe 3-2-1 : trois copies des données, sur deux supports différents, dont une hors site.

Initialiser un dépôt et créer une première archive

L’initialisation d’un dépôt chiffré se fait en une commande :

# Initialiser le dépôt avec chiffrement
borg init --encryption=repokey-blake2 /srv/backups/borg-repo

# Créer une archive nommée avec horodatage
borg create --stats --progress \
  /srv/backups/borg-repo::'{hostname}-{now:%Y-%m-%d_%H%M}' \
  /var/lib/docker/volumes \
  /etc/nginx \
  /home/deploy \
  --exclude '*.tmp' \
  --exclude '__pycache__'

La passphrase de chiffrement doit être stockée de manière sécurisée — un fichier avec permissions restreintes (chmod 600) référencé par la variable d’environnement BORG_PASSPHRASE, ou mieux, un gestionnaire de secrets.

Sauvegarder les bases PostgreSQL

Pour les bases de données, un simple backup des fichiers du volume Docker ne suffit pas — il faut un dump cohérent. Le workflow recommandé est de produire un dump SQL avant chaque sauvegarde Borg :

#!/bin/bash
# backup.sh — script de sauvegarde quotidienne

BACKUP_DIR="/srv/backups/dumps"
BORG_REPO="/srv/backups/borg-repo"
export BORG_PASSPHRASE="$(cat /root/.borg-passphrase)"

# Dump PostgreSQL (toutes les bases)
docker exec postgres pg_dumpall -U postgres \
  | gzip > "$BACKUP_DIR/pg_dumpall_$(date +%F).sql.gz"

# Dump CKAN spécifique
docker exec ckan-db pg_dump -U ckan -Fc ckan_default \
  > "$BACKUP_DIR/ckan_$(date +%F).dump"

# Sauvegarde Borg
borg create --stats --compression zstd \
  "$BORG_REPO::backup-{now:%Y-%m-%d}" \
  "$BACKUP_DIR" \
  /var/lib/docker/volumes/nextcloud_data \
  /var/lib/docker/volumes/gitea_data \
  /etc/nginx

# Nettoyage des dumps anciens
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +3 -delete
find "$BACKUP_DIR" -name "*.dump" -mtime +3 -delete

Politique de rétention

Borg permet de définir des politiques de rétention souples avec borg prune. L’idée est de garder une granularité fine pour les jours récents, puis de ne conserver qu’un snapshot par semaine ou par mois pour l’historique :

# Garder 7 quotidiennes, 4 hebdomadaires, 6 mensuelles
borg prune --stats \
  --keep-daily=7 \
  --keep-weekly=4 \
  --keep-monthly=6 \
  "$BORG_REPO"

# Compacter le dépôt (Borg 1.2+)
borg compact "$BORG_REPO"

Avec cette politique, on peut remonter jusqu’à six mois en arrière tout en limitant l’espace consommé. La déduplication de Borg fait le reste : même avec six mois d’historique, le dépôt reste remarquablement compact.

Sauvegarde distante via SSH

Pour la copie hors site, Borg supporte nativement les dépôts distants via SSH. Sur le serveur de backup, on restreint l’accès avec une clé SSH dédiée et la directive command dans authorized_keys pour n’autoriser que les commandes Borg :

# Sur le serveur de backup — ~/.ssh/authorized_keys
command="borg serve --restrict-to-path /srv/borg-remote",restrict ssh-ed25519 AAAA... deploy@prod-server

# Sur le serveur de production
borg init --encryption=repokey-blake2 ssh://backup@backup-server/srv/borg-remote/prod

borg create ssh://backup@backup-server/srv/borg-remote/prod::'{hostname}-{now}' \
  /srv/backups/dumps \
  /var/lib/docker/volumes

Automatiser et surveiller

Un timer systemd est préférable à cron pour ce type de tâche — il offre une meilleure gestion des logs et des dépendances :

# /etc/systemd/system/borg-backup.timer
[Unit]
Description=Sauvegarde Borg quotidienne

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
RandomizedDelaySec=600

[Install]
WantedBy=timers.target

Pour la supervision, intégrez le résultat de la sauvegarde à votre stack de monitoring existante (Prometheus/Grafana). Un simple exporter qui vérifie la date de la dernière archive et la taille du dépôt suffit à déclencher une alerte si une sauvegarde échoue silencieusement.

Tester la restauration

Le point le plus critique, et le plus souvent négligé. Un backup qui n’a jamais été restauré n’est qu’une hypothèse. Planifiez un test de restauration périodique — idéalement mensuel — sur un environnement isolé :

# Lister les archives disponibles
borg list /srv/backups/borg-repo

# Restaurer une archive spécifique dans un répertoire temporaire
borg extract /srv/backups/borg-repo::backup-2026-03-18 \
  --target /tmp/restore-test

# Vérifier l'intégrité du dépôt
borg check --verify-data /srv/backups/borg-repo

Un test de restauration complet inclut le rechargement du dump PostgreSQL dans une instance temporaire et la vérification que les données sont cohérentes. Automatisez ce test autant que possible — un script qui restaure, vérifie, et envoie un rapport par mail ou via un webhook est l’investissement le plus rentable de votre stratégie de sauvegarde.

Borg vs Restic : comment choisir

Restic est l’autre grand outil open source de sauvegarde avec déduplication. Il supporte nativement davantage de backends (S3, B2, Azure, GCS) et son format de dépôt est conçu pour le parallélisme. Borg, de son côté, offre une déduplication légèrement plus efficace et une maturité éprouvée. En pratique, si votre cible de stockage distant est un serveur SSH que vous contrôlez, Borg est un choix naturel. Si vous visez du stockage objet cloud (S3, MinIO), Restic sera plus adapté. Les deux sont d’excellents outils — le plus important est d’en utiliser un.

En résumé

Mettre en place BorgBackup sur une infrastructure auto-hébergée prend quelques heures. Ne pas le faire peut coûter des semaines de travail perdu. La déduplication rend le stockage abordable, le chiffrement protège les données même sur un serveur distant non maîtrisé, et les politiques de rétention permettent de remonter dans le temps sans exploser l’espace disque. Reste le réflexe le plus important : tester régulièrement que la restauration fonctionne. Un backup vérifié, c’est la tranquillité d’esprit.