Borg et Restic automatisent vos backups Linux avant que rm -rf ne frappe

Un rm -rf / s’exécute en moins de deux secondes. Un rm -rf /home en une fraction de seconde. La seule chose entre vos données et l’irréversible, c’est un backup qui tournait cette nuit. En juin 2026, deux outils open source dominent le backup Linux sérieux : BorgBackup 1.4.4 — publié le 19 mars 2026 — et Restic 0.18.1 — stable depuis septembre 2025, avec la version 0.19.0 prévue pour le 9 juin 2026.

Borg est l’arme de précision : déduplication par chunking, compression zstd, chiffrement AES-256, mode append-only qui rend le dépôt immuable face à un ransomware. Restic est le couteau suisse : mêmes garanties cryptographiques, mais avec la capacité de pousser vos snapshots vers S3, Backblaze B2, Azure, SFTP ou Google Cloud sans intermédiaire. Un backup local, c’est bien. Un backup hors-site qui survit à une panne disque ou à une erreur humaine, c’est la différence entre un incident et une catastrophe.

BorgBackup : le sniper de la déduplication

BorgBackup découpe chaque fichier en chunks de taille variable selon leur contenu — pas selon leur position. Déplacez un fichier d’un dossier à l’autre, Borg ne re-stocke rien. Modifiez 10 Go de base de données dont seuls 200 Mo ont changé : seuls 200 Mo de chunks inédits atterrissent dans le dépôt. Cette déduplication par content-defined chunking explique pourquoi un dépôt Borg de six mois de snapshots quotidiens pèse souvent moins de deux fois la taille des données originales.

Le dépôt est initialisé en une commande, avec chiffrement repokey (la clé est stockée dans le dépôt, protégée par la passphrase) ou keyfile (la clé est un fichier externe). Borg gère quatre algorithmes de compression — lz4 (ultra-rapide), zstd (bon compromis), zlib, lzma (haute compression) — et un flag --compression auto,lzma,9 pour les données peu compressibles comme les médias.

# Initialisation du dépôt Borg
borg init -e repokey-blake2 /mnt/backup/borg-repo

# Premier backup complet
borg create --stats --compression zstd,3 \
  /mnt/backup/borg-repo::$(date +%Y-%m-%d_%H:%M) \
  /home /etc /var/lib/docker/volumes

Le mode append-only est le bouclier anti-ransomware. Activé côté serveur (borg serve --append-only), il empêche toute suppression ou modification des archives existantes — même avec la passphrase. Un attaquant qui compromet le client ne peut ni supprimer les snapshots ni corrompre le dépôt. La rétention se gère côté client avec borg prune qui applique une politique configurable : garder les 7 derniers jours, les 4 derniers dimanches, les 12 derniers débuts de mois.

# Pruning : conservation 7 jours + 4 semaines + 12 mois
borg prune --list \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \
  /mnt/backup/borg-repo

Le dépôt Borg est montable en FUSE (borg mount), ce qui transforme vos snapshots en système de fichiers navigable. Restaurer un fichier supprimé devient un cp banal plutôt qu’une commande obscure.

Restic : le backup qui parle à tous les clouds

Là où Borg exige un dépôt local ou accessible en SSH, Restic parle nativement à une dizaine de backends cloud. Le même binaire Go — 27 Mo, zéro dépendance — sait écrire sur Amazon S3, Backblaze B2, Microsoft Azure Blob, Google Cloud Storage, SFTP, ou n’importe quel service compatible rclone. Cette portabilité est l’argument massue pour les environnements distribués : un VPS chez Hetzner, un NAS Synology et un bucket Wasabi partagent le même workflow.

# Backup local
restic -r /mnt/backup/restic-repo init
restic -r /mnt/backup/restic-repo backup /home /etc

# Backup vers Backblaze B2
export B2_ACCOUNT_ID=xxx B2_ACCOUNT_KEY=yyy
restic -r b2:bucket-name:/restic init
restic -r b2:bucket-name:/restic backup /home /etc

# Backup vers S3
export AWS_ACCESS_KEY_ID=xxx AWS_SECRET_ACCESS_KEY=yyy
restic -r s3:s3.amazonaws.com/bucket/restic init
restic -r s3:s3.amazonaws.com/bucket/restic backup /home /etc

La politique de rétention de Restic est plus fine que celle de Borg. La commande forget accepte des filtres par tags, host, ou chemin, et applique des règles granulaires : --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --keep-yearly 3. prune nettoie ensuite les blobs orphelins.

# Rétention Restic : 7 jours + 5 semaines + 12 mois + 3 ans
restic forget --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --keep-yearly 3 --prune

Restic chiffre tout en AES-256-CTR avec authentification Poly1305, comme Borg. La différence de surface cryptographique est marginale : les deux utilisent des primitives éprouvées, les deux sont audités, les deux supportent le changement de mot de passe sans ré-encrypter l’intégralité du dépôt. Restic 0.18.1 bénéficie d’une vérification d’intégrité supplémentaire avant upload, introduite dans la 0.17.1, qui protège contre la corruption matérielle silencieuse.

Borg vs Restic : le tableau comparatif

Restic a trois fois plus d’étoiles GitHub, un développement plus actif en surface (35 200 vs 13 600 stars, sorties plus fréquentes), et surtout une portabilité cloud native qui manque à Borg. Borg, lui, a une avance sur la maturité de la déduplication et un mode append-only qui ne dépend pas des fonctionnalités du backend — c’est un choix architectural.

Le script cron qui sauve vos nuits (et vos journées)

Un backup qui n’est pas automatisé n’existe pas. Voici le script de référence pour Borg, à placer dans /etc/cron.d/borg-backup ou dans le crontab root (crontab -e). Il inclut la vérification d’intégrité hebdomadaire et le pruning mensuel.

#!/bin/bash
# /usr/local/bin/borg-backup.sh
# À exécuter quotidiennement à 2 h du matin
# 0 2 * * * root /usr/local/bin/borg-backup.sh

export BORG_REPO="/mnt/backup/borg-repo"
export BORG_PASSPHRASE="votre-passphrase-longue-et-unique"
export BORG_RSH="ssh -i /root/.ssh/borg_key"

borg create --stats --compression zstd,3 \
  --exclude '/home/*/.cache' \
  --exclude '*.tmp' \
  "${BORG_REPO}::$(hostname)-$(date +%Y-%m-%d_%H:%M)" \
  /home /etc /var/lib/docker/volumes /srv 2>&1 | tee -a /var/log/borg-backup.log

# Pruning le premier du mois
if [ "$(date +%d)" = "01" ]; then
  borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 "${BORG_REPO}"
fi

# Vérification d'intégrité le dimanche
if [ "$(date +%u)" = "7" ]; then
  borg check "${BORG_REPO}" 2>&1 | tee -a /var/log/borg-check.log
fi

Pour Restic, le même principe, mais avec la flexibilité de pousser vers plusieurs backends simultanément. Ce script fait un backup local et une copie distante vers Backblaze B2 en deux appels. La rétention est gérée par forget --prune en une seule commande.

#!/bin/bash
# /usr/local/bin/restic-backup.sh
# 0 3 * * * root /usr/local/bin/restic-backup.sh

export RESTIC_PASSWORD="votre-passphrase-longue-et-unique"
export RESTIC_REPOSITORY="/mnt/backup/restic-repo"
export B2_ACCOUNT_ID="xxx"
export B2_ACCOUNT_KEY="yyy"

# Backup local
restic backup --exclude='/home/*/.cache' --exclude='*.tmp' \
  /home /etc /var/lib/docker/volumes /srv 2>&1 | tee -a /var/log/restic-backup.log

# Copie vers Backblaze B2 (tous les jours)
restic -r b2:bucket-name:/restic copy --from-repo "${RESTIC_REPOSITORY}"

# Rétention quotidienne
restic forget --keep-daily 7 --keep-weekly 5 \
  --keep-monthly 12 --keep-yearly 3 --prune

# Vérification d'intégrité le dimanche
if [ "$(date +%u)" = "7" ]; then
  restic check --read-data 2>&1 | tee -a /var/log/restic-check.log
fi

Les logs sont essentiels. Un backup silencieux qui échoue depuis trois semaines est pire qu’aucun backup — il donne une illusion de sécurité. La redirection tee -a garantit que vous voyez à la fois la sortie dans les logs système et dans le fichier dédié. Pour une alerte proactive, ajoutez un appel curl vers un webhook Discord/Slack ou Healthchecks.io en fin de script, conditionné au code de sortie.

Le verdict

Si vous gérez un seul serveur avec un disque de backup local ou un volume NFS monté, BorgBackup est le meilleur investissement de votre temps. Sa déduplication est plus agressive, son mode append-only intégré protège nativement contre les ransomwares, et borg mount transforme la restauration en opération triviale. Le fat binary borg-linux-glibc235 (30 Mo) s’installe en un cp — pas de Python, pas de pip, pas de venv.

Si vous avez plusieurs machines réparties chez différents hébergeurs, ou si votre stratégie inclut un backup hors-site obligatoire (et elle le devrait), Restic est le choix rationnel. Sa capacité à écrire directement sur S3, B2 ou Azure élimine la couche intermédiaire de scripts de synchronisation, et son binaire unique en Go est encore plus simple à déployer que celui de Borg. Le copy entre repos simplifie la stratégie 3-2-1 (trois copies, deux médias, un hors-site) sans outil supplémentaire.

Dans tous les cas, la pire stratégie est d’attendre le prochain rm -rf pour se souvenir qu’il fallait un backup. Deux commandes — une pour init, une dans la crontab — suffisent à passer de zéro à protégé. Le temps de les taper est inférieur au temps que vous passerez à pleurer vos données disparues.

Références

• BorgBackup 1.4.4 Release, borgbackup/borg, 19 mars 2026.
• BorgBackup Documentation — Main Features, Borg 1.4.5, readthedocs.io.
• Restic 0.18.1 Changelog, restic/restic, 21 septembre 2025.
• Restic Documentation, restic 0.19.1, readthedocs.io.
• BorgBackup — Append-Only Mode, Borg documentation.
• Restic — Preparing a New Repository, restic documentation.
• Restic — Scheduling Backups, restic documentation.
• Restic 0.19.0 Release (next version), restic/restic, 9 juin 2026.