Restic ou BorgBackup : lequel choisir pour vos backups ?

Restic contre BorgBackup, en un paragraphe

Restic et BorgBackup assurent la même fonction principale : des sauvegardes incrémentales, chiffrées et dédupliquées d'un serveur Linux. La différence qui détermine le choix est l'emplacement de destination de la sauvegarde. Restic gère nativement S3 et d'autres API de stockage objet ; un bucket est donc une cible de premier ordre sans rien à installer côté distant. Borg nécessite que le programme borg soit installé sur la machine hébergeant le dépôt, car un dépôt Borg est servi par un processus et non par un système de fichiers ou une API. Si votre cible est un stockage objet, la réponse est toute trouvée. Si votre cible est une seconde machine Linux sous votre contrôle, Borg est une option pertinente et souvent plus rapide.

Tout le reste constitue des différences mineures. Les deux outils découpent les fichiers via un découpage défini par le contenu (content defined chunking), ainsi un répertoire de 40 GB ayant changé de 200 MB ne téléverse qu'environ 200 MB. Les deux chiffrent les données sur le client. Les deux permettent de monter un snapshot avec FUSE (filesystem in userspace) pour extraire un fichier unique. En juillet 2026, restic est en version 0.19.1 et la série stable de Borg est la 1.4, en version 1.4.5. Borg 2.0 est en bêta depuis des années et reste marqué comme étant en phase de test uniquement ; la version 1.4 est donc celle que vous devez déployer aujourd'hui.

Le modèle de dépôt est la vraie différence

Un dépôt restic est un répertoire de fichiers : config, keys/, snapshots/, index/ et data/ remplis de fichiers pack. Rien d'autre n'est nécessaire pour le lire. C'est pourquoi restic peut piloter 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, ce qui explique comment 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 passif. Pour un dépôt distant, Borg démarre borg serve sur la machine distante via SSH et utilise son propre protocole pour dialoguer avec ce processus. Le côté serveur effectue un travail réel : il détient le dépôt, applique la transaction et répond aux questions sur l'index. C'est pourquoi Borg ne possède pas de backend S3 et pourquoi le projet n'en a pas ajouté. Il n'y a aucun processus à exécuter à l'intérieur d'un bucket.

Ce simple fait de conception produit 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 d'entre eux peut être désactivé

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

Borg fait du chiffrement un choix lors de la création du dépôt, et ce choix est permanent. borg init --encryption=repokey conserve la clé chiffrée à l'intérieur du dépôt, de sorte que la phrase de passe seule suffit à restaurer les données. --encryption=keyfile conserve la clé sur le client dans ~/.config/borg/keys/, ainsi une personne qui dérobe l'intégralité du dépôt ne possède rien, et vous devez donc sauvegarder ce fichier de clé séparément sous peine de rendre vos archives illisibles. Chaque mode possède une variante -blake2 qui s'authentifie avec BLAKE2b au lieu de HMAC-SHA256, ce qui est plus rapide sur le matériel sans accélération SHA. --encryption=none existe également, et constitue un choix pertinent lorsque le dépôt réside sur un disque chiffré dont vous avez la maîtrise.

La règle pratique : repokey-blake2 pour une sauvegarde de serveur classique, keyfile lorsque le dépôt est hébergé sur un emplacement auquel vous ne faites pas entièrement confiance, et n'utilisez jamais none sur une machine louée.

La compression, et pourquoi restic l'a adoptée tardivement

Borg compresse les données depuis ses débuts. La valeur par défaut est lz4, choisie car elle est suffisamment rapide pour être activée en permanence sur tout type de données. zstd accepte des niveaux de 1 à 22 avec une valeur par défaut à 3, tandis que zlib et lzma sont disponibles pour les cas où vous privilégiez l'espace disque au temps de traitement. Enfin, auto exécute une heuristique par bloc afin d'éviter de compresser deux fois des données déjà compressées.

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

Restic n'a proposé aucune 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 la valeur par défaut pour tout nouveau dépôt, et la compression se configure avec --compression via les valeurs auto, off ou max. Un ancien dépôt au format 1 reste non compressé tant que vous ne le migrez pas. Par conséquent, si votre dépôt restic est antérieur à la version 0.14 et que vous ne l'avez jamais migré, vous continuez de stocker vos textes, logs et dumps de bases de données sans aucune réduction de taille.

Cibles distantes : S3 contre SSH

C'est ici que le choix se fait généralement.

Pour que restic accède à S3, il suffit de définir les identifiants dans l'environnement, sans aucun autre processus en cours. Le même schéma fonctionne avec un bucket que vous hébergez vous-même, ce qui est une combinaison courante : exécutez MinIO pour une API S3 sur votre propre VPS et pointez restic vers celui-ci.

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 qu'un dépôt distant soit accessible avec Borg, il faut SSH et une installation de Borg sur la machine distante. La version distante doit être compatible avec celle du client. Cela représente une contrainte si vous ne gérez pas la machine distante. Ce n'est rien si la cible est un second serveur que vous administrez déjà, et cela vous offre le contrôle le plus robuste contre les ransomwares parmi les deux outils : une clé SSH en mode « append-only ». Forcez la clé à exécuter borg serve et le client pourra ajouter des archives sans pouvoir les supprimer. Ainsi, une machine compromise ne peut pas effacer son propre historique.

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

Restic propose un équivalent uniquement si vous exécutez son propre serveur REST, qui prend en charge un mode « append-only ». Avec du S3 standard, vous obtenez le même résultat via une politique de bucket ou le verrouillage d'objet (object lock), ce qui relève de la responsabilité du fournisseur et non de restic. Sécurisez également le transport, car l'accès SSH mérite le même soin que n'importe quelle autre connexion : appliquez SSH par clé uniquement avec une entrée restreinte dans authorized_keys au compte de sauvegarde.

Vitesse : ce qu'implique chaque conception

Aucun des deux projets ne publie de benchmark auquel vous devriez vous fier pour vos propres données ; raisonnez donc à partir du mécanisme.

Borg over SSH est rapide sur une liaison avec latence car le côté serveur est intelligent. Le client pose une question, le processus distant borg serve y répond à partir de l'index du dépôt, et la transaction est validée en un seul endroit. Les recherches de chunks ne se transforment pas en allers-retours réseau pour chaque petit fichier.

Restic sur du stockage objet ne possède pas de côté serveur ; il doit donc construire sa vision à partir des fichiers d'index et des fichiers pack qu'il récupère via HTTP. Pour maintenir un nombre de requêtes raisonnable, il regroupe de nombreux petits chunks dans des fichiers pack plus volumineux avant l'envoi, et il conserve un cache local dans ~/.cache/restic afin que la prochaine exécution ne télécharge pas à nouveau tout l'index. Supprimez ce cache et la sauvegarde suivante sera lente le temps de sa reconstruction. Sur une liaison à forte latence avec des millions de petits fichiers, c'est le cas de figure où restic semble plus lent que Borg sur les mêmes données.

Sur un disque local ou un LAN rapide, l'écart se réduit considérablement, et les deux outils finissent par être limités par la vitesse à laquelle ils peuvent lire et hacher la source.

Verrouillage et sauvegarde de plusieurs machines

Borg 1.4 pose un verrou exclusif sur le dépôt pendant toute la durée de l'opération. Deux clients écrivant simultanément dans un même dépôt ne fonctionnent pas : le second attend, puis échoue avec un délai d'attente de verrouillage dépassé. Le modèle pris en charge est un dépôt par client. Cela signifie également que la déduplication ne s'effectue qu'au sein du dépôt d'une seule machine ; ainsi, dix serveurs quasi identiques stockent dix copies du même système de base.

Restic permet à plusieurs clients de sauvegarder simultanément dans un même dépôt, car une sauvegarde pose un verrou partagé et seules les opérations de maintenance telles que prune nécessitent un verrou exclusif. Dix serveurs similaires pointant vers un dépôt restic se dédupliquent entre eux, et le second serveur et les suivants stockent souvent très peu de données. Le coût est le rayon d'impact : un seul mot de passe et un seul dépôt contenant tout, donc la perte du mot de passe entraîne la perte des dix sauvegardes.

Rétention : forget et prune, versus prune et compact

Les deux outils séparent la décision de ce qu'il faut conserver de la récupération d'espace, et les deux imposent d'exécuter la seconde étape.

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 identique dans les deux outils et mérite d'être énoncé clairement. Dans Borg, borg prune supprime des archives mais ne libère pas d'espace disque par lui-même. L'espace est récupéré lors de l'exécution de borg compact ; ainsi, une tâche cron qui effectue un prune sans jamais compacter laisse un dépôt dont la taille augmente indéfiniment alors que la liste des archives reste courte. Dans restic, forget sans --prune supprime uniquement les références aux snapshots, et les données restent présentes jusqu'à l'exécution d'un prune.

Exécutez restic check après un prune. Cette commande vérifie les structures du dépôt et vous signale si un élément est endommagé, ce qui est préférable à une découverte lors d'une restauration.

La restauration, le seul test qui compte

Les deux outils montent un snapshot pour vous permettre de le parcourir. C'est la méthode la plus rapide pour récupérer un fichier unique.

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 la barre oblique initiale, donc etc/nginx est correct et /etc/nginx ne correspond à rien et n'extrait rien, sans message d'erreur pour vous en informer. L'extraction écrit également dans le répertoire de travail actuel ; changez donc d'abord pour un répertoire temporaire, sinon vous écraserez des fichiers actifs par des anciens.

Quel que soit l'outil choisi, le planning ne représente que la moitié du travail. Effectuez une restauration dans un répertoire temporaire selon une fréquence que vous surveillez réellement, de la même manière que le guide complet dans le guide de sauvegarde restic pour un VPS le fait avec un timer systemd.

Lequel choisir pour quelle tâche

Choisissez restic si la cible est un stockage objet, si vous voulez un binaire unique sans logiciel à installer sur la destination, si plusieurs machines doivent dédupliquer leurs données entre elles, ou si la personne effectuant la restauration n'est pas vous. Il s'agit d'un binaire statique unique utilisant une URL pour le dépôt, ce qui est difficile à battre sur le plan opérationnel.

Choisissez Borg si la cible est une machine Linux que vous contrôlez, si la liaison présente de la latence et que le jeu de données contient des millions de petits fichiers, si vous voulez utiliser une clé SSH en mode append-only pour vous protéger contre les ransomwares, ou si vous souhaitez ajuster la compression par tâche. C'est l'outil le plus ancien, sa série 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 décrit dans la configuration de Nextcloud sur Docker avec dumps de base de données s'applique aux deux outils, car un fichier de base de données actif copié à un instant aléatoire ne constitue pas une sauvegarde de base de données.

FAQ

Est-ce que restic ou BorgBackup est plus rapide ?

Sur un disque local ou un réseau local rapide, les performances sont proches et toutes deux finissent par être limitées par la vitesse de lecture et de hachage sur la source. Borg a tendance à être plus performant sur une liaison SSH à haute latence avec un grand nombre de petits fichiers, car un processus borg serve distant répond aux questions d'index sans aller-retour réseau par bloc. Restic a tendance à être plus performant lorsque la cible est un stockage objet, là où Borg ne peut pas fonctionner du tout.

BorgBackup peut-il sauvegarder vers S3 ou Backblaze B2 ?

Pas directement. Un dépôt Borg est servi par le processus borg serve via SSH, et aucun processus de ce type ne s'exécute à l'intérieur d'un bucket. Certains utilisateurs contournent cette limitation en montant le stockage objet comme un système de fichiers avec rclone, ce que le projet Borg déconseille, car un montage qui s'interrompt au milieu d'une transaction peut corrompre le dépôt. Si vous avez besoin de stockage objet, utilisez restic.

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

Oui, et certains le font : Borg vers un second serveur pour une restauration locale rapide, et restic vers un stockage objet pour la copie hors site. Ils ne partagent rien, vous payez donc deux fois le coût de lecture et de hachage, et vous avez deux mots de passe à conserver en sécurité. Ne faites cela que 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. Borg en mode repokey stocke la clé chiffrée à l'intérieur du dépôt, donc la phrase secrète seule permet la restauration, et en mode keyfile vous avez également besoin du fichier de clé situé dans ~/.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 juillet 2026, Borg 2.0 est toujours en bêta, à la version 2.0.0b22, et le projet le qualifie uniquement pour des tests. La série stable est la 1.4, actuellement en 1.4.5. Commencez avec la 1.4 dès maintenant. Borg 2 modifie le format du dépôt et propose un chemin de mise à niveau documenté, donc commencer aujourd'hui ne vous bloquera pas.