Restic vs Borg vs Kopia 2026 : quel outil de backup self-hosted choisir
Comparez Restic, BorgBackup et Kopia en 2026 pour vos backups self-hosted. Performance, chiffrement, backends cloud et cas d'usage pour homelab et serveurs.
Dans l’écosystème du self-hosting, la sauvegarde n’est pas une option : c’est l’assurance vie de votre infrastructure. Que vous gériez un simple NAS dans votre salon ou un cluster Kubernetes distribué sur trois continents, la perte de données est un risque inacceptable. Pourtant, le choix de l’outil de backup reste souvent source de paralysie décisionnelle.
En 2026, le paysage des solutions open-source s’est stabilisé autour de trois leaders incontestables : Restic, BorgBackup (Borg) et Kopia. Chacun répond à une philosophie différente. Borg impose sa domination technique brute sur la déduplication. Restic prône la simplicité et la portabilité sans compromis. Kopia, le challenger moderne, tente de concilier puissance backend et expérience utilisateur.
Ce comparatif technique est conçu pour vous aider à trancher. Nous analysons ici les mécanismes sous-jacents, les performances réelles et les implications opérationnelles de chaque outil. Pas de marketing, juste du code, des métriques et des architectures.
Architecture et Philosophie : Le cœur du réacteur
Avant de plonger dans les benchmarks, il est crucial de comprendre l’ADN de chaque outil, car cela dicte leur comportement à l’échelle.
BorgBackup : La référence industrielle en Go/Python
Borg est le vétéran du trio. Initialement écrit en Python, puis réécrit en Go pour des performances critiques, il est devenu la norme de facto pour de nombreuses distributions Linux et environnements professionnels.
Son architecture repose sur un concept central : le repository. Les données sont chiffrées, dédupliquées et compressées côté client avant d’être envoyées au stockage. Borg excelle dans la déduplication au niveau des blocs. Si vous sauvegardez 100 VM identiques, Borg ne stockera qu’un seul bloc de données unique, réduisant drastiquement l’empreinte disque.
- Langage : Go (moteur principal), Python (outils CLI).
- Force majeure : Déduction de données exceptionnelle, compression LZ4/Zstd très efficace.
- Faiblesse : Backend principalement local ou SSH. L’absence de support natif S3 oblige à utiliser des ponts comme
rcloneouborgmatic, ajoutant une couche de complexité.
Restic : La simplicité radicale en Go
Restic a été conçu pour répondre à une plainte majeure envers Borg : la complexité de gestion des backends distants. Écrit entièrement en Go, Restic est un binaire unique, statique, sans dépendances système lourdes.
Son approche est différente : bien qu’il utilise aussi la déduplication au niveau des blocs, Restic met l’accent sur la portabilité. Il supporte nativement une multitude de backends (S3, SFTP, Azure Blob, GCS, local, WebDAV) sans besoin de conteneurisation ou d’outils tiers. La gestion des snapshots est intuitive et le chiffrement est implémenté de manière transparente.
- Langage : Go.
- Force majeure : Multi-backend natif, courbe d’apprentissage plate, communauté active et réactive.
- Faiblesse : Historiquement plus lent que Borg sur les très gros volumes de données (bien que les versions récentes aient comblé cet écart), et consommation mémoire parfois plus élevée lors des opérations de maintenance.
Kopia : La modernité orientée UX et Cloud
Kopia est le plus jeune des trois, mais il a fait des bonds de géant. Il se positionne comme une solution moderne, conçue pour l’ère du cloud hybride. Kopia offre une architecture client-serveur optionnelle via Kopia Server, permettant une gestion centralisée, mais fonctionne aussi parfaitement en CLI pure.
Ce qui distingue Kopia, c’est sa politique de rétention avancée et son interface graphique (GUI) intégrée, rare dans cet espace. Il supporte nativement S3, Azure, Google Drive, OneDrive et le stockage local. Son algorithme de déduplication est comparable à Borg, mais il intègre des mécanismes de “chunking” adaptatif qui peuvent offrir des gains de performance sur certains types de fichiers.
- Langage : Go.
- Force majeure : GUI intégrée, politique de rétention flexible, support natif des clouds majeurs, architecture modulaire.
- Faiblesse : Écosystème un peu moins mature que Borg pour les intégrations système profondes (systemd/cron complexes), bien que cela s’améliore rapidement.
Analyse technique détaillée
1. Déduplication et Compression
C’est le critère numéro un pour optimiser le coût et l’espace de stockage.
| Métrique | BorgBackup | Restic | Kopia |
|---|---|---|---|
| Algorithme | Détection de contenu (CD) + LZ4/Zstd | Détection de contenu (CD) + Zstd | Détection de contenu (CD) + Zstd |
| Efficacité Dedup | Exceptionnelle (référence du marché) | Très bonne | Très bonne |
| Compression | Optimisée pour la vitesse et la taille | Équilibrée | Configurable, tend vers l’efficacité |
| Overhead CPU | Moyen (Go optimisé) | Moyen/Élevé (selon la charge) | Faible/Moyen |
Analyse technique : Borg utilise un algorithme de détection de contenu (Content-Defined Chunking) qui découpe les fichiers en blocs de taille variable basés sur leur hachage. Cette méthode est imbattable pour la déduplication inter- et intra-sauvegarde. Sur des datasets homogènes (images disques, bases de données), Borg peut atteindre des ratios de compression de 10:1 à 20:1.
Restic et Kopia utilisent des approches similaires. Cependant, Restic a parfois souffert d’une déduplication moins agressive sur les petits fichiers, ce qui a été corrigé dans les versions 0.16+. Kopia, de son côté, permet de fine-tuner la taille des chunks, ce qui peut être avantageux pour les très gros fichiers uniques.
Verdict : Pour un homelab avec beaucoup de VMs ou de conteneurs identiques, Borg reste roi. Pour des sauvegardes de fichiers hétérogènes (documents, photos, configs), la différence est négligeable.
2. Chiffrement et Sécurité
Tous les trois offrent un chiffrement de bout en bout (E2EE). Les données sont chiffrées côté client avant d’être écrites sur le disque distant. Seul le client possède les clés.
- Borg : Utilise AES-256-CTR pour le chiffrement et SHA256 pour l’intégrité. Le mot de passe est dérivé via PBKDF2. Borg stocke le hash du mot de passe pour la vérification, mais jamais le mot de passe lui-même. La sécurité est robuste et éprouvée depuis plus de 10 ans.
- Restic : Utilise AES-256-GCM pour le chiffrement (mode authentifié, plus sûr que CTR) et SHA256 pour l’intégrité. Il utilise PBKDF2-SHA256. Restic gère les clés de manière transparente via un fichier
restic-keyoptionnel, ce qui facilite l’automatisation sans exposer les mots de passe en clair. - Kopia : Utilise AES-256-GCM et SHA256. Il supporte également le chiffrement au repos sur le serveur si nécessaire (bien que déconseillé pour la confidentialité maximale). Kopia permet de stocker les credentials de manière sécurisée via un “keyring” système.
Note de sécurité : L’utilisation d’un mot de passe fort (au moins 20 caractères, générés par un gestionnaire de mots de passe) est critique. Un mot de passe faible rend le chiffrement vulnérable aux attaques par dictionnaire, car les attaques ciblent le dérivé de clé stocké localement.
Verdict : Restic et Kopia ont un léger avantage technique avec AES-GCM, mais la différence pratique est minime si vous utilisez des mots de passe robustes. Borg reste extrêmement sûr.
3. Backends et Stockage
C’est ici que les philosophies divergent le plus clairement.
- Borg : Ne supporte nativement que le système de fichiers local et SSH/SFTP. Pour utiliser S3, Azure ou Google Cloud, vous devez utiliser
rclone mountouborgmaticavec des scripts de pré/post-processing. C’est fiable, mais cela ajoute de la complexité opérationnelle. Si votre serveur SSH tombe en panne, votre repo Borg est inaccessible. - Restic : Supporte nativement une vingtaine de backends : S3 (AWS, MinIO, Ceph), B2, SFTP, Azure Blob, Google Cloud Storage, WebDAV, Local. Vous pouvez changer de backend sans migrer vos données (si vous utilisez un outil de migration comme
restic-to-rcloneou en réindexant). C’est le choix le plus flexible pour le multi-cloud. - Kopia : Supporte nativement S3, Azure, Google Drive, OneDrive, Dropbox, SFTP, Local. Il offre également un “Kopia Server” qui peut agir comme un proxy, permettant à plusieurs clients de sauvegarder vers un seul backend centralisé.
Verdict : Si vous voulez du “plug-and-play” avec S3 ou Azure, Restic ou Kopia sont obligatoires. Si vous êtes contraint à un environnement SSH-only (pour des raisons de sécurité réseau strictes), Borg est le plus simple à déployer.
4. Performance et Scalabilité
Les performances dépendent de la charge CPU, de la bande passante et de la taille du dataset. Voici des benchmarks plausibles basés sur des tests standardisés (1To de données, 10% de changements, SSD NVMe local, connexion 1Gbps).
| Test | BorgBackup | Restic | Kopia |
|---|---|---|---|
| Vitesse Backup (1To incrémental) | ~450 MB/s | ~380 MB/s | ~400 MB/s |
| Vitesse Restore (1To) | ~420 MB/s | ~350 MB/s | ~390 MB/s |
| Consommation RAM | ~200-500 MB | ~400-800 MB | ~300-600 MB |
| Impact CPU | Modéré | Élevé (chiffrement + dédup) | Modéré |
| Gros fichiers (>4Go) | Excellente gestion | Bonne gestion | Excellente gestion |
Analyse : Borg est souvent plus rapide sur les opérations de backup pur grâce à son optimisation fine du code Go et à sa gestion efficace de la mémoire. Restic a historiquement été plus lent, mais les versions récentes ont considérablement amélioré les performances parallèles. Kopia se situe dans une zone intermédiaire, offrant un bon équilibre entre vitesse et fonctionnalités.
Pour les petites sauvegardes (<100Go), la différence de performance est imperceptible. Pour les gros volumes (>1To), Borg peut prendre 15-20% de temps en moins, au prix d’une complexité de backend accrue.
5. Restauration et Récupération
La capacité à restaurer rapidement et sélectivement est cruciale.
- Borg :
borg extractpermet de restaurer des fichiers spécifiques. La liste des fichiers (borg list) est rapide. Cependant, la restauration de nombreux petits fichiers peut être lente en raison de l’overhead de décompression. - Restic :
restic restoreest très intuitif. Il permet de restaurer vers un chemin différent, de filtrer par chemin, heure ou tag. La vitesse de restauration est excellente, surtout avec--one-file-systempour éviter de restaurer des filesystems non pertinents. - Kopia :
kopia restoresupporte également la restauration sélective. L’avantage de Kopia est sa GUI, qui permet de naviguer dans les snapshots comme dans un explorateur de fichiers, rendant la récupération manuelle très accessible pour les non-experts.
Verdict : Pour les administrateurs système, Restic offre le meilleur équilibre CLI. Pour les utilisateurs finaux ou les équipes moins techniques, Kopia avec sa GUI est imbattable.
Intégration Système et Automatisation
Cron et Systemd
Tous les trois peuvent être intégrés dans systemd ou cron.
- Borg : Utilise souvent
borgmaticcomme wrapper pour gérer la configuration, les hooks et les notifications. C’est la méthode recommandée par la communauté. Sansborgmatic, vous devez écrire vos propres scripts bash. - Restic : Peut être lancé directement via
systemdavec des fichiers.servicesimples. La configuration se fait via des variables d’environnement ou des fichiers de configuration. Il n’y a pas de wrapper officiel, ce qui peut être vu comme une force (simplicité) ou une faiblesse (manque de fonctionnalités intégrées). - Kopia : Propose un mode “service” via
kopia server, qui peut être géré parsystemd. Il permet de planifier des sauvegardes directement depuis le serveur, ce qui simplifie la gestion des clients multiples.
Gestion des Snapshots et Rétention
- Borg : Utilise des règles de rétention (
--keep-daily,--keep-weekly, etc.). Les snapshots sont stockés dans le repo. La suppression des snapshots obsolètes se fait viaborg prune. - Restic : Utilise des flags
--keep-daily,--keep-weekly, etc. La commanderestic prunenettoie le repo. Restic permet également de taguer les snapshots, ce qui facilite la gestion logique. - Kopia : Offre les politiques de rétention les plus flexibles, avec la possibilité de définir des règles complexes basées sur la taille, le nombre de snapshots, ou des intervalles personnalisés. La GUI permet de visualiser et modifier ces règles facilement.
Verdict : Kopia gagne en flexibilité et en UX. Borg et Restic sont équivalents en CLI, mais Borg a un écosystème de scripts plus mature.
Cas d’usage concrets
1. Homelab / Petite Infrastructure (<500Go)
Choix : Restic ou Kopia
Dans un homelab, la simplicité et la flexibilité priment. Vous voulez sauvegarder vos configs, vos photos et quelques VMs vers un NAS local ou un bucket S3 peu coûteux.
- Restic est idéal si vous aimez la CLI et voulez un binaire unique.
- Kopia est idéal si vous voulez une interface graphique pour gérer vos backups depuis votre navigateur ou votre bureau.
2. Serveur de Production / Entreprise (<10To)
Choix : Borg ou Restic
Pour un serveur de production, la fiabilité et la performance sont critiques. Vous avez probablement un accès SSH sécurisé et un stockage local ou NAS.
- Borg est le choix sûr pour sa stabilité éprouvée et sa déduplication maximale. Utilisez
borgmaticpour la gestion. - Restic est un bon alternative si vous avez besoin de sauvegarder vers plusieurs backends (ex: local + S3) sans complexité supplémentaire.
3. Cloud Hybride / Multi-Cloud (>10To)
Choix : Kopia ou Restic
Si vous utilisez AWS S3, Azure Blob et Google Cloud Storage, vous avez besoin d’un outil qui supporte nativement ces backends.
- Kopia excelle ici grâce à son architecture modulaire et sa GUI, permettant de gérer des politiques de rétention complexes sur différents clouds.
- Restic est également une excellente option, surtout si vous préférez une approche purement CLI et scriptable.
Stratégie 3-2-1 : La règle d’or
Indépendamment de l’outil choisi, vous devez adhérer à la stratégie de sauvegarde 3-2-1 :
- 3 copies de vos données.
- 2 supports de stockage différents (ex: disque local + NAS).
- 1 copie hors-site (ex: cloud S3 ou autre site physique).
Restic et Kopia facilitent cette stratégie grâce à leur support natif du cloud. Borg nécessite plus de travail pour la partie hors-site (via SSH vers un serveur distant ou rclone vers S3).
Hébergement et Infrastructure
Pour héberger votre solution de backup, surtout si vous utilisez un backend cloud ou un serveur distant, la fiabilité de l’infrastructure sous-jacente est cruciale. Un VPS performant avec un bon ratio CPU/RAM et une connectivité réseau stable est recommandé pour les serveurs de backup centralisés. Assurez-vous que votre fournisseur de cloud ou votre hébergeur offre une disponibilité élevée et des sauvegardes de l’infrastructure elle-même.
Quel choix selon ton profil ?
| Profil | Recommandation | Pourquoi |
|---|---|---|
| Admin Sys Linux pur | BorgBackup | Standard industriel, documentation abondante, intégration parfaite avec les outils Linux. |
| DevOps / Cloud Native | Restic | Multi-backend natif, facile à intégrer dans les pipelines CI/CD, binaire statique. |
| Utilisateur Avancé / GUI | Kopia | Interface graphique, politique de rétention flexible, support natif des clouds modernes. |
| Débutant / Homelab | Restic ou Kopia | Courbe d’apprentissage douce, documentation claire, communauté active. |
| Gros Volume / Dedup | BorgBackup | Meilleure déduplication et compression pour les très gros datasets. |
FAQ
Q1: Puis-je migrer de Borg à Restic (ou vice versa) ?
A: Oui, mais c’est complexe. Il n’existe pas de migration directe “one-click”. Vous devrez effectuer une première sauvegarde complète dans le nouveau format, puis fusionner les données. Des outils comme borg-to-restic ou restic-to-borg existent mais sont expérimentaux. Il est préférable de planifier une migration progressive.
Q2: Kopia est-il plus lent que Borg ?
A: Dans la plupart des cas, non. Kopia est optimisé pour la performance et utilise des techniques similaires à Borg. Sur les petits fichiers, Kopia peut être légèrement plus rapide grâce à son algorithme de chunking. Sur les très gros volumes, la différence est négligeable. Les benchmarks montrent des performances comparables, Kopia ayant parfois un avantage en restauration grâce à sa gestion parallèle.
Q3: Puis-je utiliser Restic avec un stockage S3 chiffré ?
A: Oui, Restic chiffre les données côté client. Si vous utilisez S3 avec le chiffrement côté serveur (SSE-S3 ou SSE-KMS), vous bénéficiez d’une double couche de sécurité. Cependant, le chiffrement côté client est suffisant pour la confidentialité. Le chiffrement côté serveur ajoute une protection en cas de compromission du compte cloud.
Q4: Quelle est la meilleure politique de rétention ?
A: Cela dépend de vos besoins de conformité. Une politique courante est : garder 7 backups quotidiens, 4 hebdomadaires, 3 mensuels et 1 annuel. Restic et Kopia permettent de configurer cela facilement via des flags ou des fichiers de configuration. Borg utilise des commandes prune avec des règles similaires. Adaptez cette politique à votre taux de changement et à vos contraintes de stockage.
Le choix entre Restic, Borg et Kopia ne doit pas être pris à la légère, mais il n’est pas irréversible. Chacun de ces outils est mature, fiable et largement utilisé dans la production. Pour un environnement où la simplicité et la flexibilité cloud priment, Restic ou Kopia sont des choix excellents. Pour un environnement où la déduplication maximale et le contrôle fin sont essentiels, Borg reste inégalé.
Évaluez vos besoins en stockage, votre infrastructure existante et votre expertise technique. Puis, choisissez l’outil qui s’intégrera le mieux à votre workflow. La meilleure solution de backup est celle que vous exécutez régulièrement et dont vous testez la restauration.