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.