Kopia

Kopia est un outil de sauvegarde open source qui transforme fichiers et dossiers en snapshots chiffrés et dédupliqués, puis les stocke là où l’espace existe déjà : un bucket S3, un compte Backblaze B2, un NAS joignable en SFTP, ou un simple dossier sur une seconde machine. Rien à faire tourner en face. Un repository Kopia, c’est un emplacement de stockage plus un mot de passe, point final : n’importe quel client qui s’y connecte (un portable, un serveur, une autre machine pointée vers le même bucket) déduplique directement contre ce qui y est déjà stocké. Le projet livre à la fois un binaire en ligne de commande et une interface graphique baptisée KopiaUI, construits depuis la même base de code, donc scripter une tâche nocturne ou cliquer pour restaurer un fichier sont deux usages aussi bien couverts l’un que l’autre.

Kopia est-il toujours activement maintenu en 2026 ?

Oui, et largement. Le dépôt kopia/kopia sur GitHub dépasse les 13 500 étoiles, affiche 86 versions taguées et plus de 4 100 commits, la dernière version stable, la v0.23.1, ayant été publiée en juin 2026. L’image Docker officielle suit ce rythme à travers les tags latest, testing et unstable, et le site de documentation montre des commits aussi récents que juillet 2026. Pas de bandeau « archivé », pas de trou de maintenance à justifier, ce qui n’est pas donné à tous les outils de sauvegarde de cette catégorie.

Ce que fait réellement Kopia

Une politique de snapshot définit ce qui est sauvegardé, à quelle fréquence, ce qu’il faut ignorer via des règles .kopiaignore, combien de temps les anciens snapshots restent conservés, et si les données sont compressées avant d’être chiffrées. Le premier snapshot envoie tout ; chacun des suivants ne traite que ce qui a changé, puisque les fragments identiques existent déjà dans le repository sous le même hash de contenu. La restauration passe par la CLI, par l’interface graphique, ou en montant un snapshot comme un système de fichiers navigable en lecture seule, pratique pour récupérer un seul fichier dans la sauvegarde de mardi dernier sans tout restaurer. Une tâche de maintenance optionnelle tourne en arrière-plan pour compacter les anciennes données et libérer de l’espace une fois que les politiques de rétention font expirer les snapshots les plus vieux.

Le modèle de repository : pourquoi Kopia se passe de serveur de sauvegarde

C’est le point qui distingue vraiment Kopia d’un outil de sauvegarde client-serveur classique, et celui qui revient le plus souvent quand on le compare à Duplicati. Sous le repository se cache une couche que Kopia appelle Content-Addressable Block Storage : chaque fragment de données est haché en SHA2 ou BLAKE2S, ce hash devient l’identifiant du fragment, puis il est chiffré en AES256-GCM ou CHACHA20-POLY1305 et regroupé dans des paquets de 20 à 40 Mo avant d’être envoyé vers le stockage. Deux fragments identiques, qu’ils viennent du même fichier sauvegardé deux fois ou de deux machines différentes partageant un repository, produisent le même hash et ne sont stockés qu’une seule fois, sans qu’aucun processus serveur n’arbitre quoi que ce soit. Le backend de stockage objet est la seule chose commune entre les clients ; chacun hache et compare de son côté, indépendamment des autres. Un Kopia Repository Server existe pour les équipes qui veulent un contrôle d’accès centralisé, mais c’est une brique optionnelle pour un cas d’usage précis, pas un prérequis pour démarrer.

Installer Kopia avec Docker

L’image officielle kopia/kopia attend un mot de passe de repository via la variable d’environnement KOPIA_PASSWORD, plus quelques dossiers montés : /app/config pour le fichier de connexion au repository, /app/cache pour les données téléchargées, et l’emplacement de stockage lui-même s’il est local plutôt que dans le cloud.

$ docker run -e KOPIA_PASSWORD \
-v /path/to/config:/app/config \
-v /path/to/cache:/app/cache \
-v /path/to/logs:/app/logs \
-v /path/to/repository:/repository \
-v /path/to/tmp:/tmp:shared \
kopia/kopia:latest

Faire tourner Kopia en mode serveur, la configuration qui expose l’interface web sur le port 51515, ressemble à ceci en Compose :

services:
  kopia:
    image: kopia/kopia:latest
    container_name: kopia
    hostname: kopia
    restart: unless-stopped
    ports:
      - 51515:51515
    command:
      - server
      - start
      - --disable-csrf-token-checks
      - --insecure
      - --address=0.0.0.0:51515
      - --server-username=USERNAME
      - --server-password=CHANGE_THIS_PASSWORD
    environment:
      - KOPIA_PASSWORD=CHANGE_THIS_REPOSITORY_PASSWORD
    volumes:
      - ./config:/app/config
      - ./cache:/app/cache
      - ./logs:/app/logs
      - /path/to/data:/data:ro
      - /path/to/repository:/repository
      - /path/to/tmp:/tmp:shared

Cas d’usage en homelab

L’usage évident, c’est la sauvegarde hors site et dédupliquée de ce qui tourne déjà en self-hosted : un dossier de données Nextcloud, une bibliothèque photo Immich, une archive Paperless-ngx, ou une poignée de dumps de bases de données, envoyés vers Backblaze B2 ou le NAS d’un proche plutôt que de faire confiance à un seul disque. Comme le modèle de repository ne demande aucun serveur dédié, sauvegarder plusieurs machines vers un même bucket partagé fonctionne sans rien provisionner de plus ; un serveur maison et un portable peuvent dédupliquer contre le même repository s’ils stockent des données qui se recoupent. Le déploiement suit le même chemin que n’importe quel autre conteneur, via Dockge ou Portainer, et comme Duplicati, Kopia se prête mal aux mises à jour automatiques façon Watchtower, vu la complication qu’un redémarrage en plein snapshot pourrait causer.

Kopia face à Duplicati et Restic

Duplicati et Restic répondent à un problème voisin, mais atterrissent à des endroits différents. La déduplication de Duplicati vit dans une base de données locale propre à chaque tâche plutôt que dans un repository partagé et adressé par hash, donc deux tâches Duplicati distinctes ne dédupliquent jamais entre elles, même en sauvegardant vers la même destination. Kopia et Restic utilisent tous les deux un vrai format de repository adressable par contenu, donc n’importe quel client qui partage ce repository profite automatiquement de la déduplication. Là où ils divergent, c’est sur l’interface : Restic reste CLI de bout en bout, sans tableau de bord fourni, tandis que Kopia embarque une interface graphique dans le même paquet, plus proche dans l’esprit de l’interface web de Duplicati sans sacrifier la scriptabilité que les habitués de Restic recherchent.

Catégorie	Kopia	Duplicati	Restic
Modèle de déduplication	Stockage par blocs adressable par contenu, basé sur des hash, partagé entre tous les clients du repository	Base de données locale par tâche qui suit les blocs modifiés ; les tâches ne dédupliquent pas entre elles	Découpage en blocs défini par le contenu dans un repository partagé, modèle proche de Kopia
Serveur central requis	Non, tout client muni du mot de passe se connecte directement	Non, mais pas de déduplication inter-tâches non plus	Non, même modèle de repository que Kopia
Interface	CLI et interface graphique (KopiaUI) depuis la même base de code	Interface web intégrée	CLI uniquement, aucune interface fournie
Licence	Apache License 2.0	MIT	BSD-2-Clause

Kopia : avantages et inconvénients

• Gratuit et open source sous Apache License 2.0, sans compte ni clé de licence requis
• Repository adressable par contenu : le stockage partagé entre plusieurs machines déduplique automatiquement, sans processus serveur
• CLI et interface graphique issues de la même base de code, toujours synchronisées
• Protection anti-ransomware optionnelle via verrouillage d’objets et clés d’accès restreintes sur les backends compatibles

• Aucun planificateur intégré en dehors des politiques propres à KopiaUI ; les installations CLI seules doivent passer par cron ou systemd timers
• Restaurer un seul fichier en montant un snapshot est un flux moins direct qu’une restauration en un clic dans une interface web classique
• Écosystème d’intégrations de stockage préconstruites plus restreint que la quarantaine de backends de Duplicati

FAQ

Kopia est-il gratuit ?

Oui, entièrement, sous Apache License 2.0. Il n’existe ni palier payant, ni compte, ni clé de licence.

Kopia est-il toujours activement développé ?

Oui. Le dépôt GitHub dépasse les 86 versions publiées et 4 100 commits en juin 2026, la dernière version stable, la v0.23.1, datant du même mois.

Kopia a-t-il besoin d’un serveur de sauvegarde dédié ?

Non. Un repository Kopia, c’est du stockage chiffré protégé par un mot de passe ; n’importe quel client muni de ce mot de passe s’y connecte directement et déduplique contre son contenu. Un Kopia Repository Server n’existe que pour un contrôle d’accès centralisé entre plusieurs utilisateurs, et reste optionnel.

Kopia ou Duplicati : lequel choisir ?

Duplicati convient mieux à qui veut une interface web qui gère planification et restauration sans toucher à un terminal, avec la plus large liste de destinations prises en charge. Kopia convient mieux quand la déduplication réelle entre plusieurs machines compte vraiment, ou quand une interface graphique et une CLI scriptable doivent fonctionner à partir du même repository.

Kopia se positionne juste à côté de Duplicati parmi les options de sauvegarde self-hosted les plus activement développées à l’approche de 2026 : un vrai repository adressable par contenu, un rythme de publication sans trou à justifier, et des protections anti-ransomware que peu d’outils de sauvegarde proposent. Pour qui fait déjà tourner Duplicati et se demande si la déduplication est meilleure ailleurs, voilà une réponse concrète, avec un lien à suivre plutôt qu’un nom dans un tableau comparatif.