Restic règne sur le segment "sauvegarde dédupliquée chiffrée open source" depuis 2015. Solide, en Go, simple à scripter, large communauté. Mais Kopia a comblé son retard et pris l'avantage sur plusieurs points opérationnels en 2025-2026 : parallélisme natif, UI web, scheduling intégré, politiques de rétention plus fines.
Velero, le standard de fait pour la sauvegarde Kubernetes, a basculé Restic vers Kopia comme moteur par défaut courant 2024. Ce signal seul justifie qu'on regarde sérieusement Kopia côté ops, même si Restic reste une cible parfaitement valide pour beaucoup de workloads.
Ce qui suit n'est pas un benchmark de salon. C'est ce qu'on regarde quand on doit choisir entre les deux pour de la prod.
Plan de l'article
- Architecture et modèle de données
- Déduplication : ce que mesurent vraiment les deux outils
- Performance et parallélisme
- UI, scheduling, ergonomie
- Politiques de rétention et compaction
- Backends supportés et chiffrement
- Cas d'usage où chacun gagne
- Migration entre les deux
Architecture et modèle de données
Les deux outils partagent les mêmes principes : déduplication par chunks variable-size, chiffrement client-side AES-GCM, snapshots immuables, backend agnostique (filesystem, S3, B2, GCS, Azure, SFTP).
Restic découpe les données en chunks de taille variable (CDC, Content-Defined Chunking) avec un rolling hash. Chunks indexés et stockés dans un repository structuré : data/, index/, snapshots/, keys/. Format stable depuis 2015. Le repo est compatible toutes versions ascendantes.
Kopia utilise aussi du CDC mais avec des paramètres tunables (splitter configurable, hashPercentage). Le repository ajoute des objets : pack, index, manifests, compaction. Format documenté, plus structuré pour les opérations de maintenance.
Côté ops, Restic est plus simple à introspecter avec des outils standard. Kopia demande de comprendre son modèle d'objets, mais le payoff est meilleur sur le long terme.
Déduplication : ce que mesurent vraiment les deux outils
Sur des workloads serveurs typiques (filesystems Linux, dumps DB, vmail), les ratios sont proches.
| Workload | Restic | Kopia |
| Filesystem Linux mixte (50 Go) | 60-80% | 65-82% |
| Dumps PostgreSQL incrémentaux | 75-85% | 78-87% |
| VM disk images quotidiens | 92-97% | 93-98% |
| Repos Git multiples | 50-60% | 50-65% |
| Maildir Dovecot | 40-55% | 45-60% |
Les écarts viennent surtout de la taille de chunk par défaut. Kopia utilise des chunks plus petits pour les petits fichiers, ce qui améliore le ratio sur les workloads avec beaucoup de fichiers de quelques Ko (mail, sources de code).
Pour des workloads orientés gros fichiers (backups VM, datasets, médias), les deux convergent vers 95-99% de déduplication sur des cycles incrémentaux. La différence est dans le bruit.
Conclusion : sur la déduplication brute, ce n'est pas un critère de choix décisif. Les écarts mesurés ne valent pas la migration.
Performance et parallélisme
C'est ici que Kopia gagne nettement.
Restic, par défaut, lit séquentiellement les fichiers à sauvegarder et upload séquentiellement vers le backend. Sur un repo S3 ou B2, le débit est limité par la latence des PUT (40-100ms par requête). Sur un backup initial de 500 Go, ça prend des heures même avec 1 Gbps de bande passante.
Kopia parallélise par défaut. Multiple goroutines qui lisent, chiffrent et uploadent en parallèle. Les benchmarks montrent jusqu'à 4x de gain sur des backends S3-like. Sur des SSD locaux ou NFS, le gain est moindre (CPU et IO local saturent vite).
Sur la consommation CPU, Restic est plus gourmand par MB traité. Kopia utilise zstd par défaut (Restic utilise zlib historiquement, zstd disponible plus récemment). Notre article zstd compression détaille pourquoi le standard a basculé vers zstd dans la plupart des piles modernes.
Pour de la prod backup nightly avec fenêtre serrée (par exemple sauvegarde DB de 200 Go entre 2h et 5h du matin), Kopia délivre la fenêtre que Restic peut rater.
UI, scheduling, ergonomie
Restic est CLI-only. La sauvegarde se schedule via cron, systemd timer, ou un wrapper comme resticprofile, autorestic, backrest. La supervision passe par les logs JSON et un script qui les ingère vers Prometheus ou Loki. Pour le scheduling production, on utilise systemd timers ou cron.
Kopia embarque :
- une UI web (
kopia server) pour parcourir les snapshots et restaurer en quelques clics - un scheduler interne avec policies (chaque source peut avoir son schedule, sa rétention, ses exclusions)
- un mode
Kopia UIElectron pour les postes de travail
L'UI Kopia n'est pas un gadget. Pour une équipe qui a 50 sources à gérer (serveurs hétérogènes, VMs, postes), l'UI permet une vue d'ensemble immédiate. Avec Restic, il faut construire ce dashboard soi-même.
Côté ergonomie, Restic gagne sur la simplicité du binaire unique scriptable. Kopia gagne sur la couverture fonctionnelle out-of-the-box.
Politiques de rétention et compaction
Restic gère la rétention via forget + prune. Politiques exprimées en CLI : --keep-daily 7 --keep-weekly 4 --keep-monthly 12. Le prune est l'opération qui efface les chunks orphelins, et il a longtemps été lent et bloquant. L'option --max-unused (depuis 0.12) permet de différer le prune pour gagner en performance, en acceptant un overhead temporaire.
Kopia attache la politique de rétention à la source ou au global. Granularité : par-source, par-utilisateur, par-tag. La compaction (équivalent du prune) est conçue pour être incrémentale et non-bloquante. On peut continuer à sauvegarder pendant qu'une compaction tourne.
Pour un opérateur qui doit articuler une stratégie 3-2-1 stricte avec retention différenciée par classe de données (DB = 30j quotidien + 1 an mensuel ; logs = 7j ; vmail = 90j + 5 ans annuel), Kopia rend le mapping plus naturel.
Backends supportés et chiffrement
Backends communs : filesystem, SFTP, S3 et compatibles, B2, Azure Blob, GCS, OneDrive (Restic), WebDAV.
Spécifiques Restic : REST server officiel (très utile pour des sauvegardes append-only), Rclone backend (par extension, accès à 70+ stockages).
Spécifiques Kopia : Tigris, Storj, Filebase (S3 compat avec spécificités).
Chiffrement : AES-256-GCM client-side dans les deux cas. Kopia ajoute le support de chiffrement par identités (pour le partage repo entre plusieurs équipes avec droits différenciés), Restic reste sur une clé maître unique avec sous-clés dérivées.
Pour des sauvegardes vers MinIO local et Wasabi distant comme on le décrit dans restic + MinIO + Rclone, les deux outils fonctionnent. La nuance : Restic + REST server append-only est une solution d'immutabilité native bien rodée pour le scénario "même un attaquant root sur le client ne peut pas effacer les sauvegardes". Kopia s'appuie plutôt sur l'object lock S3 du backend.
Cas d'usage où chacun gagne
| Scénario | Recommandation |
| Sauvegarde serveur Linux unique, scriptée | Restic |
| Backup parc 50+ machines avec UI | Kopia |
| Sauvegarde Velero / Kubernetes | Kopia (défaut Velero) |
| Sauvegarde DB scriptée vers S3 | Restic ou Kopia, peu de différence |
| Sauvegarde initiale très volumineuse (>500 Go) | Kopia (parallélisme) |
| Append-only strict via REST | Restic |
| Compatibilité maximum (long terme, format stable) | Restic |
| Multi-utilisateur partagé | Kopia (identités) |
Sur les backups Borg legacy, notre article Borg + PostgreSQL reste valide pour les contextes Borg, mais on ne recommande plus de partir sur du Borg neuf en 2026 (pas de support cloud natif, pas de parallélisme).
Migration entre les deux
Pas de format d'échange direct. Pour migrer Restic vers Kopia :
- Garder le repo Restic en place pour la rétention historique (lecture seule).
- Démarrer un nouveau repo Kopia avec une politique fraîche.
- Faire tourner les deux en parallèle pendant la fenêtre de rétention Restic.
- Au bout de 1 an (typique), retirer le repo Restic.
L'autre sens (Kopia vers Restic) suit la même logique. Pas de bascule "bouton magique" possible : les modèles de chunks et d'index ne sont pas compatibles.
Pièges communs aux deux
Restauration testée. Une sauvegarde non restaurée n'est pas une sauvegarde. Tester trimestriellement. Restaurer un volume complet sur une VM de test, vérifier la cohérence applicative (DB qui boot, app qui monte). Sans ça, le jour J on découvre que le backup avait un problème depuis 6 mois.
Vérification d'intégrité. Les deux exposent une commande de check. Restic : restic check --read-data (lent mais complet). Kopia : kopia maintenance run --full. À schedule mensuel.
Compaction et fenêtre. Le prune Restic peut bloquer plusieurs heures sur un gros repo. Le planifier hors heures ouvrées. Kopia est plus gentil mais demande quand même son créneau.
Stockage cloud cost. Sur S3-like, attention aux retrieval costs (Glacier, Deep Archive). Pour de l'archivage 7 ans, le lifecycle S3 est l'outil, pas le moteur backup.
Clé de chiffrement. Stockée hors du serveur sauvegardé, dans un coffre-fort (Vault, KMS, HSM). Sans la clé, la sauvegarde est inaccessible. C'est trivial à dire, oublié dans 30% des audits qu'on fait.
Sur les architectures backup qu'on opère pour nos clients, on bascule progressivement vers Kopia pour les déploiements neufs (UI, parallélisme), et on garde Restic sur les piles existantes tant que la migration ne se justifie pas. Si vous opérez un parc Restic vieillissant et que vous voulez chiffrer le coût et le bénéfice d'une bascule Kopia avant d'engager, on peut auditer votre dispositif et cadrer la trajectoire en un sprint.
Sources
- Restic documentation officielle : architecture, commandes, troubleshooting.
- Kopia documentation officielle : référence pour scheduling, policies, backends.
- Velero choosing Kopia as default - CloudCasa : analyse du basculement Velero.
- Restic GitHub repository : code, releases, issues.
- Kopia GitHub repository : code, releases, roadmap.
- Content-defined chunking - LWN article : fondations algorithmiques de la déduplication des deux outils.
