Restic ou BorgBackup : lequel choisir ?

Restic ou BorgBackup, en un paragraphe

Restic et BorgBackup assurent tous deux la même fonction principale : des sauvegardes dédupliquées, chiffrées et incrémentielles d’un serveur Linux. Le critère qui détermine le choix est l’emplacement de la sauvegarde. Restic prend nativement en charge S3 et d’autres API de stockage objet. Un bucket constitue donc une cible de premier niveau, sans rien installer sur le système distant. Borg nécessite l’installation du programme borg sur la machine qui héberge le repository, car un repository Borg est fourni par un processus, et non par un filesystem ou une API. Si votre cible est un stockage objet, le choix est déjà fait. Si votre cible est une deuxième machine Linux que vous contrôlez, Borg convient et sera souvent plus rapide.

Le reste correspond à des différences secondaires. Les deux outils découpent les fichiers en fonction de leur contenu. Ainsi, si un répertoire de 40 GB a été modifié à hauteur de 200 MB, environ 200 MB sont envoyés. Les deux outils chiffrent les données côté client. Les deux permettent de monter un snapshot avec FUSE (filesystem in userspace), afin de copier un fichier spécifique. En juillet 2026, Restic est en version 0.19.1 et la série stable de Borg est la version 1.4, actuellement en 1.4.5. Borg 2.0 est en bêta depuis des années et est toujours indiqué comme réservé aux tests. Vous devez donc déployer la version 1.4 aujourd’hui.

Le modèle de dépôt fait toute la différence

Un dépôt restic est un répertoire de fichiers : config, keys/, snapshots/, index/ et data/, qui contiennent des fichiers pack. Rien d’autre n’est nécessaire pour le lire. C’est pourquoi restic peut utiliser autant de backends. Tout stockage capable de déposer, récupérer, lister et supprimer des blobs peut héberger un dépôt restic. C’est ainsi qu’un seul binaire prend en charge les chemins locaux, SFTP, son propre serveur REST, S3, Backblaze B2, Azure, Google Cloud Storage et tout ce que rclone peut atteindre.

Un dépôt Borg est également constitué de fichiers sur disque, mais Borg ne communique jamais avec lui via un transport sans logique. Pour un dépôt distant, Borg démarre borg serve sur le serveur distant via SSH et utilise son propre protocole pour communiquer avec ce processus. Le serveur effectue un véritable traitement : il héberge le dépôt, applique la transaction et répond aux requêtes sur les index. C’est pourquoi Borg ne dispose pas de backend S3 et pourquoi le projet n’en a pas ajouté. Aucun processus ne peut être exécuté à l’intérieur d’un bucket.

Ce seul choix de conception explique la plupart des différences pratiques ci-dessous.

# restic: the repository is a URL, and the backend is part of it
restic -r /srv/restic-repo init
restic -r sftp:backup@198.51.100.20:/srv/restic-repo init
restic -r s3:s3.us-east-1.amazonaws.com/my-backup-bucket init

# borg: a local path, or user@host:path, with borg installed on that host
borg init --encryption=repokey-blake2 /srv/borg/vps1
borg init --encryption=repokey-blake2 backup@198.51.100.20:/srv/borg/vps1

Chiffrement : l’un des deux peut être désactivé

Restic chiffre toujours les données. Il n’existe pas de mode non chiffré. restic init demande un mot de passe, en dérive une clé avec scrypt, puis chiffre et authentifie chaque fichier pack écrit ensuite. Si vous perdez le mot de passe, les données sont perdues, car aucune procédure de récupération n’est prévue par conception.

Borg fait du chiffrement un choix effectué lors de la création du dépôt, et ce choix est définitif. borg init --encryption=repokey conserve la clé chiffrée dans le dépôt : la phrase secrète suffit donc pour restaurer les données. --encryption=keyfile conserve la clé sur le client, dans ~/.config/borg/keys/. Ainsi, une personne qui vole le dépôt complet ne possède toujours pas la clé. Vous devez donc sauvegarder ce fichier de clé séparément, faute de quoi vos archives seront illisibles. Chaque mode propose une variante -blake2 qui utilise BLAKE2b au lieu de HMAC-SHA256 pour l’authentification. Elle est plus rapide sur le matériel dépourvu d’accélération SHA. --encryption=none existe également. C’est un choix pertinent lorsque le dépôt se trouve sur un disque chiffré que vous contrôlez.

La règle pratique est la suivante : utilisez repokey-blake2 pour une sauvegarde normale d’un serveur, keyfile lorsque le dépôt se trouve dans un environnement auquel vous ne faites pas entièrement confiance, et n’utilisez jamais none sur une machine louée.

Compression et pourquoi restic l’a ajoutée tardivement

Borg compresse les données depuis ses débuts. La valeur par défaut est lz4, car elle est suffisamment rapide pour être activée partout. zstd accepte les niveaux 1 à 22 et utilise 3 par défaut. zlib et lzma conviennent lorsque la taille compte davantage que la durée d’exécution. auto applique une heuristique à chaque chunk afin d’éviter de compresser une seconde fois les données déjà compressées.

borg create --compression zstd,3 --stats --progress \
  /srv/borg/vps1::'{hostname}-{now}' /etc /home /srv

Restic ne prenait pas du tout en charge la compression avant le format de dépôt 2, qui nécessite restic 0.14.0 ou une version ultérieure. Le format 2 est maintenant utilisé par défaut pour les nouveaux dépôts. La compression se configure avec --compression, avec les valeurs auto, off ou max. Un ancien dépôt au format 1 reste non compressé tant que vous ne le migrez pas. Si votre dépôt restic date d’avant la version 0.14 et que vous ne l’avez jamais migré, les fichiers texte, les journaux et les dumps de base de données occupent toujours leur taille complète.

Cibles distantes : S3 ou SSH

C’est généralement à ce stade que le choix se fait.

Pour accéder à S3, restic a besoin d’identifiants dans l’environnement, et rien d’autre ne doit être exécuté ailleurs. Le même modèle fonctionne avec un bucket que vous hébergez vous-même. C’est une association courante : exécutez MinIO pour fournir une API S3 sur votre propre VPS et configurez restic pour l’utiliser.

export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://objects.example.com/backups
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /home /srv --exclude-caches

Pour accéder à un dépôt distant, Borg a besoin de SSH et d’une installation de Borg sur le serveur distant. La version installée doit être compatible avec celle du client. Cela peut être contraignant si vous n’administrez pas le serveur distant. Ce n’est pas un problème s’il s’agit d’un deuxième serveur que vous administrez déjà. Vous bénéficiez alors de la meilleure protection contre les ransomwares proposée par ces deux outils : une clé SSH en mode append only. Forcez cette clé à exécuter borg serve. Le client peut alors ajouter des archives, mais pas les supprimer. Une machine compromise ne peut donc pas effacer son propre historique.

command="borg serve --append-only --restrict-to-path /srv/borg/vps1",restrict ssh-ed25519 AAAA...

Restic offre un mécanisme équivalent uniquement si vous exécutez son propre serveur REST, qui prend en charge le mode append only. Avec un S3 standard, vous obtenez le même résultat grâce à une bucket policy ou à l’object lock. Cette protection relève du fournisseur, pas de restic. Sécurisez également le transport, car la partie SSH mérite la même attention que toute autre connexion : appliquez SSH avec clé uniquement et une entrée authorized_keys restreinte au compte de sauvegarde.

Vitesse : ce que chaque conception implique

Aucun des deux projets ne publie de benchmark fiable pour vos propres données. Il faut donc raisonner à partir du fonctionnement de chaque outil.

Borg over SSH est rapide sur une liaison à forte latence, car la partie serveur est intelligente. Le client pose une question, le processus distant borg serve y répond à partir de l’index du repository, puis la transaction est validée à un seul endroit. La recherche des chunks ne se transforme pas en aller-retours réseau pour chaque petit fichier.

Restic sur un object storage ne dispose d’aucune partie serveur. Il doit donc reconstituer son état à partir des fichiers d’index et des pack files récupérés via HTTP. Pour limiter le nombre de requêtes, il regroupe de nombreux petits chunks dans des pack files plus volumineux avant l’upload. Il conserve aussi un cache local dans ~/.cache/restic afin de ne pas récupérer à nouveau tout l’index lors de l’exécution suivante. Si vous supprimez ce cache, la sauvegarde suivante est lente, car elle doit le reconstruire. Sur une liaison à forte latence avec des millions de petits fichiers, c’est le cas où restic paraît plus lent que Borg sur les mêmes données.

Sur un disque local ou un réseau local rapide, l’écart se réduit principalement. Les deux outils sont alors surtout limités par la vitesse à laquelle ils peuvent lire et calculer le hash de la source.

Verrouillage et sauvegarde de plusieurs machines

Borg 1.4 verrouille exclusivement le dépôt pendant toute l’opération. Deux clients ne peuvent pas écrire simultanément dans un même dépôt : le second attend, puis échoue lorsque le délai d’attente du verrou est dépassé. Le modèle pris en charge consiste à utiliser un dépôt par client. La déduplication ne s’effectue donc qu’au sein du dépôt d’une seule machine. Dix serveurs presque identiques stockent ainsi dix copies du même système de base.

Restic permet à plusieurs clients d’effectuer simultanément des sauvegardes dans un même dépôt, car une sauvegarde utilise un verrou partagé. Seules les opérations de maintenance, comme prune, utilisent un verrou exclusif. Dix serveurs similaires utilisant un même dépôt restic dédupliquent leurs données entre eux. Le deuxième serveur ajoute souvent très peu de données. En contrepartie, l’impact d’une compromission est plus important : un seul mot de passe protège un dépôt qui contient tout. Si vous perdez ce mot de passe, vous perdez les sauvegardes des dix serveurs.

Rétention : forget plus prune, contre prune plus compact

Les deux outils séparent la décision de ce qu’il faut conserver de la récupération de l’espace, et vous devez exécuter la deuxième étape dans les deux cas.

restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
restic check

borg prune --list --glob-archives '{hostname}-*' \
  --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /srv/borg/vps1
borg compact /srv/borg/vps1

Le piège est le même avec les deux outils. Il faut l’indiquer clairement. Avec Borg, borg prune supprime les archives, mais ne libère pas l’espace disque à lui seul. L’espace est récupéré lorsque borg compact s’exécute. Une tâche cron qui exécute prune sans jamais lancer compact laisse donc un repository qui grossit indéfiniment, alors que la liste des archives reste courte. Avec restic, forget sans --prune supprime uniquement les références aux snapshots. Les données restent présentes jusqu’à l’exécution de prune.

Exécutez restic check après prune. Cette commande vérifie les structures du repository et vous indique si un élément est endommagé. C’est préférable à la découverte du problème pendant une restauration.

La restauration est le seul test qui compte

Les deux outils montent un snapshot pour vous permettre de le parcourir. C’est le moyen le plus rapide de récupérer un fichier.

restic snapshots
restic restore latest --target /tmp/restore --include /etc/nginx
restic mount /mnt/restore

borg list /srv/borg/vps1
borg extract --list /srv/borg/vps1::vps1-2026-07-30T02:00:00 etc/nginx
borg mount /srv/borg/vps1::vps1-2026-07-30T02:00:00 /mnt/restore

Notez la forme du chemin dans borg extract. Les chemins à l’intérieur d’une archive sont stockés sans slash initial. etc/nginx est donc correct, tandis que /etc/nginx ne correspond à rien et n’extrait rien, sans message d’erreur indiquant la cause. L’extraction écrit également dans le répertoire de travail courant. Placez-vous donc d’abord dans un répertoire de travail temporaire, faute de quoi vous risquez d’écraser des fichiers actifs avec d’anciennes copies.

Une restauration qui se termine sans erreur ne constitue pas une preuve suffisante. L’application utilise sa propre définition d’une restauration complète. Un serveur Immich reconstruit à partir d’une copie du répertoire de données Postgres peut retrouver toutes les photos sur le disque tout en affichant une timeline vide. C’est précisément le problème que la sauvegarde et la restauration d’Immich doivent résoudre.

Quel que soit l’outil choisi, la planification ne représente que la moitié du travail. Lancez régulièrement une restauration dans un répertoire de travail temporaire et surveillez-la réellement, comme le fait le guide complet de sauvegarde restic pour un VPS avec un timer systemd.

Quel outil choisir selon le besoin

Choisissez restic si la cible est un stockage objet, si vous voulez un seul binaire sans installer de logiciel sur la machine distante, si plusieurs machines doivent dédupliquer leurs données entre elles ou si la restauration peut être effectuée par une autre personne. Il s’agit d’un binaire statique unique, auquel il suffit d’indiquer l’URL d’un dépôt. Difficile de faire mieux sur le plan opérationnel.

Choisissez Borg si la cible est une machine Linux que vous contrôlez, si la liaison présente une latence élevée et que le jeu de données contient des millions de petits fichiers, si vous voulez utiliser une clé SSH append-only comme protection contre les ransomwares ou si vous voulez régler la compression pour chaque tâche. C’est l’outil le plus ancien. Sa branche stable évolue lentement, ce qui est un avantage pour un logiciel de sauvegarde.

Les deux sont de bons choix. Le mauvais choix est celui que vous ne testez jamais. Si vous effectuez déjà des dumps au niveau applicatif, conservez-les : le modèle présenté dans la configuration Nextcloud avec Docker et des dumps de base de données s’applique aux deux outils, car la copie d’un fichier de base de données en fonctionnement à un instant arbitraire ne constitue pas une sauvegarde de cette base de données.

FAQ

Restic ou BorgBackup est-il plus rapide ?

Sur un disque local ou un réseau local rapide, les performances sont proches. Les deux outils sont finalement limités par la vitesse de lecture et de calcul des hash sur la source. Borg est généralement plus rapide sur une connexion SSH à latence élevée contenant un très grand nombre de petits fichiers, car un processus borg serve sur le serveur distant répond aux requêtes sur l’index sans effectuer un aller-retour réseau pour chaque chunk. Restic est généralement plus rapide avec un stockage objet, auquel Borg ne peut pas accéder directement.

BorgBackup peut-il sauvegarder vers S3 ou Backblaze B2 ?

Pas directement. Un dépôt Borg est fourni par le processus borg serve via SSH, et aucun processus de ce type ne s’exécute dans un bucket. Une solution consiste à monter le stockage objet comme un système de fichiers avec rclone. Le projet Borg ne le recommande pas, car un montage interrompu au milieu d’une transaction peut corrompre le dépôt. Si vous avez besoin d’un stockage objet, utilisez restic.

Puis-je utiliser les deux outils avec les mêmes données ?

Oui, c’est le cas pour certains utilisateurs : Borg vers un second serveur pour une restauration locale rapide, et restic vers un stockage objet pour la copie hors site. Les outils ne partagent rien. Vous payez donc deux fois le coût de lecture et de calcul des hash, et vous devez conserver deux mots de passe en sécurité. Faites-le uniquement si vous avez testé les deux restaurations.

Que se passe-t-il si je perds le mot de passe du dépôt ?

Les données sont irrécupérables avec les deux outils. Restic dérive sa clé du mot de passe avec scrypt et il n’existe aucun contournement. En mode repokey, Borg stocke la clé chiffrée dans le dépôt : la phrase secrète suffit donc pour restaurer les données. En mode keyfile, vous avez également besoin du fichier de clé provenant de ~/.config/borg/keys/. Conservez le mot de passe dans un gestionnaire de mots de passe qui ne se trouve pas sur le serveur sauvegardé. Exportez la clé Borg avec borg key export si vous utilisez keyfile.

Dois-je attendre Borg 2.0 ?

Non. En juillet 2026, Borg 2.0 est toujours en bêta, en version 2.0.0b22, et le projet le réserve aux tests. La série stable est la 1.4, actuellement en version 1.4.5. Commencez dès maintenant avec la version 1.4. Borg 2 modifie le format des dépôts et fournit une procédure de mise à niveau documentée. Commencer aujourd’hui ne vous bloquera donc pas.