Restic ou BorgBackup : lequel choisir ?

Restic ou BorgBackup, en un paragraphe

Restic et BorgBackup assurent 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 la destination de la sauvegarde. Restic prend en charge nativement S3 et d’autres API de stockage objet. Un bucket constitue donc une destination de premier niveau, sans rien installer sur le système distant. La version stable de Borg nécessite l’installation du programme borg sur la machine qui héberge le dépôt, car un dépôt Borg est fourni par un processus, et non par un système de fichiers ou une API. Si votre destination est un stockage objet, le choix est déjà fait. Si votre destination est un deuxième serveur Linux que vous contrôlez, Borg est adapté et souvent plus rapide.

Le reste correspond à des différences secondaires. Les deux outils découpent les fichiers en utilisant un chunking défini par le contenu. Ainsi, si un répertoire de 40 GB a changé de 200 MB, environ 200 MB sont téléversés. Les deux outils chiffrent les données sur le client. Les deux permettent de monter un snapshot avec FUSE (filesystem in userspace), afin de récupérer un fichier. En octobre 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 est la véritable 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 qu’rclone peut atteindre.

Un dépôt Borg consiste également en des fichiers sur disque, mais Borg ne communique jamais avec lui via un transport rudimentaire. 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. La partie serveur effectue le vrai travail : elle conserve le dépôt, applique la transaction et répond aux requêtes sur l’index. C’est pourquoi la série stable Borg 1.4 ne possède pas de backend S3. Aucun processus ne peut être exécuté dans un bucket. Borg 2 change cette architecture : le stockage est déplacé dans une nouvelle couche appelée borgstore, et sa documentation décrit les URL de dépôt sftp://, rclone:remote:path et s3: ou b2:. Borg 2 est toutefois encore une version bêta que le projet déconseille d’utiliser en production. Pour les sauvegardes réelles aujourd’hui, l’absence de backend S3 reste donc un problème.

Ce seul choix d’architecture explique la plupart des différences pratiques présentées 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 arrivée tardive de cette fonctionnalité dans restic

Borg compresse les données depuis le début. 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 par défaut le niveau 3. zlib et lzma sont destinés aux cas où la taille compte davantage que le temps d’exécution. auto applique une heuristique à chaque chunk afin d’éviter de compresser une seconde fois des 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 désormais utilisé par défaut pour les nouveaux dépôts. La compression se configure avec --compression, en choisissant l’une des cinq valeurs suivantes : auto (valeur par défaut), off, fastest, better ou max. Les modes fastest et better sont apparus dans restic 0.19.0. Les anciens binaires n’acceptent donc que auto, off et 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 0.14 et que vous ne l’avez jamais migré, les fichiers texte, les logs et les dumps de bases 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, ils sont proches, et tous deux finissent par être limités par la vitesse de lecture et de calcul des hash sur la source. Borg a tendance à être plus rapide sur une connexion SSH à forte latence contenant beaucoup de petits fichiers, car un processus borg serve sur l’autre machine répond aux requêtes d’index sans effectuer un aller-retour réseau pour chaque chunk. Restic a tendance à être plus rapide avec un object storage, auquel Borg stable ne peut pas accéder directement.

BorgBackup peut-il sauvegarder vers S3 ou Backblaze B2 ?

Pas avec la série stable 1.4. Un dépôt Borg 1.4 est servi par le processus borg serve via SSH, et aucun processus de ce type ne s’exécute dans un bucket. Borg 2 ajoute les URL de dépôt s3:, b2: et rclone: via sa couche borgstore, mais en octobre 2026, Borg 2 est toujours en bêta et le projet recommande de ne pas l’utiliser en production. Avec 1.4, on contourne cette limitation en montant l’object storage comme un système de fichiers avec rclone. La FAQ de Borg déconseille les systèmes de fichiers réseau pour stocker les dépôts et avertit que FUSE et les systèmes de fichiers réseau peuvent provoquer des ralentissements ou une corruption. Si vous avez besoin d’un object storage pour vos sauvegardes de production aujourd’hui, utilisez restic.

Puis-je exécuter les deux outils sur les mêmes données ?

Oui, certaines personnes le font : Borg vers un deuxième serveur pour une restauration locale rapide, et restic vers un object storage pour la copie hors site. Ils ne partagent rien. Vous payez donc deux fois le coût de lecture et de calcul des hash, et vous devez stocker 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. 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é, et exportez la clé Borg avec borg key export si vous utilisez keyfile.

Dois-je attendre Borg 2.0 ?

Non. En octobre 2026, Borg 2.0 est toujours en bêta, en version 2.0.0b25 (publiée le 27 septembre 2026), et le projet la destine uniquement aux tests. La série stable est la 1.4, actuellement en version 1.4.5. Commencez dès maintenant avec 1.4. Borg 2 modifie le format des dépôts et fournit une procédure de mise à niveau documentée (borg transfer --from-borg1). Commencer aujourd’hui ne vous bloquera donc pas. Borg 2 est également la version qui apporte la prise en charge native de S3, B2 et rclone, une fois qu’elle sera stable.