plakar : sauvegarde chiffrée et dédupliquée

plakar est une solution de sauvegarde et restauration open-source (licence ISC) qui prend des snapshots chiffrés et dédupliqués de vos données. Vous créez un dépôt (chiffré par défaut), vous sauvegardez un dossier en une commande, chaque sauvegarde ne stocke que ce qui a changé, et vous parcourez vos données depuis une interface web sans tout restaurer. Ce guide montre comment installer plakar, créer un dépôt, sauvegarder, naviguer dans les snapshots, gérer la rétention, répliquer hors site et restaurer. Il s'adresse aux administrateurs et développeurs qui cherchent une alternative moderne à restic ou borg. Toutes les commandes ont été exécutées sur la version 1.1.3.

Ce que vous allez apprendre

Installer plakar (version épinglée) et comprendre le moteur Kloset
Créer un dépôt chiffré et protéger sa passphrase
Sauvegarder, lister, et naviguer dans les snapshots (cat, diff, mount, interface web)
Appliquer une rétention (rm, policy, prune, maintenance)
Répliquer hors site (règle 3-2-1) et restaurer une sauvegarde vérifiée

Prérequis

Go 1.23.3+ pour l'installation par go install (ou un binaire pré-compilé).
Un dossier de données à sauvegarder et un emplacement pour le dépôt.
Pour l'interface web : un navigateur sur la machine ou un accès réseau au port choisi.

Installer plakar

plakar est écrit en Go et se distribue en binaire unique. Épinglez une version précise plutôt que @latest pour des installations reproductibles.

go install
Binaire / paquet

go install github.com/PlakarKorp/plakar@v1.1.3

Le binaire est installé dans $(go env GOPATH)/bin. Ajoutez ce dossier à votre PATH si besoin.

Téléchargez le binaire correspondant à votre système depuis la page officielle https://www.plakar.io/download/, ou via Homebrew :

brew install plakar

Vérifiez l'installation :

plakar version

plakar/v1.1.3

Comment plakar stocke vos données : le moteur Kloset

Avant de sauvegarder, il faut comprendre où vont les données. plakar repose sur Kloset, un magasin de données immuable : vos fichiers sont découpés en chunks (morceaux à taille variable), regroupés dans des packfiles, puis indexés par des états qui décrivent chaque snapshot. Ce découpage est la base de la déduplication : un même contenu n'est stocké qu'une fois, quel que soit le nombre de fichiers ou de snapshots qui le référencent.

La commande info révèle les algorithmes réellement employés par un dépôt :

plakar at /var/backups/repo info

Chunking:
 - Algorithm: fastcdc-v1.0.0
 - MinSize: 512 KiB
 - NormalSize: 1.0 MiB
 - MaxSize: 8.0 MiB
Hashing:
 - Algorithm: BLAKE3
Compression:
 - Algorithm: LZ4
Encryption:
 - SubkeyAlgorithm: AES256-KW
 - DataAlgorithm: AES256-GCM-SIV
 - KDF: ARGON2ID

Plusieurs choix techniques méritent l'attention. Le découpage CDC (fastcdc) repère les frontières de chunks par le contenu, pas par une position fixe : insérer un octet au début d'un fichier ne décale donc pas tous les chunks suivants, et la déduplication reste efficace. Le hachage BLAKE3 adresse les chunks par leur empreinte. La déduplication opère avant le chiffrement : plakar dédoublonne sur le contenu en clair, puis chiffre, ce qui combine gain d'espace et confidentialité sans exposer vos données à l'infrastructure de stockage.

Le chiffrement lui-même est solide : dérivation de clé Argon2id (résistante au brute-force), chiffrement des données en AES-256-GCM-SIV et enveloppe de clés en AES-256-KW. Ces choix ne sont pas anodins : ils correspondent aux recommandations d'un audit cryptographique externe mené par le cryptographe Jean-Philippe Aumasson. L'audit ayant été commandité par l'éditeur, il ne remplace pas votre propre évaluation, mais c'est un gage de sérieux rare pour un outil jeune.

Créer un dépôt chiffré

Un dépôt (repository, ou kloset) est l'espace où plakar stocke vos snapshots. Par défaut, plakar opère sur ~/.plakar ; pour viser un autre emplacement, la syntaxe place toujours le dépôt après le mot-clé at. Créez-en un :

plakar at /var/backups/repo create

plakar chiffre le dépôt par défaut et demande une passphrase. Pour scripter la création (CI, automatisation), fournissez-la par variable d'environnement :

export PLAKAR_PASSPHRASE="votre-passphrase-robuste"
plakar at /var/backups/repo create

L'option globale -keyfile lit la passphrase depuis un fichier (prioritaire sur la variable d'environnement), pratique pour un service non interactif. L'option -plaintext désactive le chiffrement (déconseillé), et -weak-passphrase autorise une passphrase faible (à éviter en production).

La passphrase, point de défaillance unique

Sans passphrase, toute opération sur le dépôt s'arrête sur une invite repository passphrase:. C'est le bon réflexe de sécurité, mais le revers est sans appel : perdez la passphrase, perdez la sauvegarde. plakar n'a aucun mécanisme de récupération de clé. Stockez-la dans un gestionnaire de secrets et gardez-en une copie hors ligne, jamais uniquement sur la machine sauvegardée, sinon un sinistre emporte les données et la clé de leurs sauvegardes.

Sauvegarder un dossier

Une sauvegarde crée un snapshot identifié par un identifiant court. Ajoutez un tag pour retrouver et filtrer vos sauvegardes plus tard :

plakar at /var/backups/repo backup -tag site-web /srv/www

3a95e3f4: backup completed without errors in 108ms (in: 0 B, out: 5.4 MiB)

Vous pouvez sauvegarder plusieurs sources en une fois (backup /etc /srv/www) et exclure des motifs avec -ignore ou -ignore-file. Listez ensuite les snapshots du dépôt :

plakar at /var/backups/repo ls

2026-06-25T19:15:11Z   3a95e3f4   229 B   0s   /srv/www   tags=site-web

Déduplication et sauvegardes incrémentales

Relancez une sauvegarde après avoir modifié un seul fichier : plakar ne traite que le delta, pas l'ensemble des données.

27d4028b: backup completed without errors in 130ms (in: 14 KiB, out: 2.0 MiB)

Ici, in: 14 KiB confirme que seul le contenu changé a été lu : les données inchangées ne sont pas recopiées. La déduplication évite en plus de stocker deux fois un contenu identique au sein d'une même sauvegarde comme entre snapshots.

Pourquoi le dépôt peut sembler plus gros que les données

Sur un petit jeu de test, le dépôt peut dépasser le volume sauvegardé : par exemple 8,9 Mo de dépôt pour 3 Mo de données. La raison est un overhead fixe (index, état, structure des packfiles) de l'ordre de 5 à 6 Mo, qui domine tant que les données sont peu volumineuses. Les gains de déduplication et de compression n'apparaissent qu'à l'échelle, sur de vrais volumes répétitifs et un historique de snapshots : ne jugez pas plakar sur un dossier jouet.

Naviguer dans une sauvegarde sans tout restaurer

L'intérêt d'un dépôt adressé par contenu, c'est d'inspecter une sauvegarde sans la restaurer entièrement. plakar offre plusieurs commandes pour cela, ce qui change la façon de travailler au quotidien : on cherche un fichier précis plutôt que de dérouler une archive complète.

Affichez le contenu d'un fichier d'un snapshot directement sur la sortie standard :

plakar at /var/backups/repo cat 27d4028b:/srv/www/conf/app.ini

theme=clair
lang=fr
nouveau=1

Comparez deux snapshots pour voir ce qui a changé entre deux sauvegardes, en diff unifié :

plakar at /var/backups/repo diff 3a95e3f4:/srv/www/conf/app.ini 27d4028b:/srv/www/conf/app.ini

@@ -1,3 +1,4 @@
-theme=sombre
+theme=clair
 lang=fr
+nouveau=1

Retrouvez un fichier par motif à travers tous les snapshots, sans savoir dans lequel il se trouve :

plakar at /var/backups/repo locate '*.conf'

27d4028b:/srv/www/conf/nginx.conf
3a95e3f4:/srv/www/conf/nginx.conf

Monter une sauvegarde comme un disque

La commande mount expose un snapshot comme un système de fichiers en lecture seule. Vous parcourez vos sauvegardes avec ls, cat, votre éditeur ou votre explorateur, sans extraction préalable :

plakar at /var/backups/repo mount -to /mnt/backup

Le tableau de bord web

Pour une vue d'ensemble graphique, lancez l'interface web intégrée :

plakar at /var/backups/repo ui -no-spawn -addr 127.0.0.1:9090

launching webUI at http://127.0.0.1:9090?plakar_token=d8d4cd33-3a05-4def-96d8-a020f23224bb

Le dashboard sert une application web et une API JSON locale pour parcourir les snapshots, inspecter leur contenu et restaurer. L'accès est protégé par un token présent dans l'URL de lancement : ne le partagez pas. L'option -no-spawn évite d'ouvrir un navigateur (utile sur un serveur distant), et fournir -cert/-key active HTTPS. Pour exposer le dépôt à d'autres machines plutôt qu'une UI, voyez la commande server plus loin.

Restaurer une sauvegarde

La restauration extrait un snapshot vers un dossier cible, en le désignant par son identifiant :

plakar at /var/backups/repo restore -to /tmp/restore 27d4028b

27d4028b: OK ✓ /conf/nginx.conf
27d4028b: OK ✓ /html/index.html

La restauration extrait à la racine de la cible

restore -to /tmp/restore dépose le contenu du snapshot directement à la racine du dossier cible (/tmp/restore/conf/nginx.conf), et non sous un sous-dossier reproduisant le chemin d'origine. Restaurez donc toujours dans un dossier vide et dédié : viser un dossier déjà peuplé risque d'écraser des fichiers existants. Vérifiez la cible avant de lancer la commande.

Vérifier l'intégrité

Une sauvegarde ne vaut que si elle est relisible. plakar vérifie l'intégrité du dépôt et des snapshots :

plakar at /var/backups/repo check

check completed without errors

L'option -fast accélère le contrôle en validant la structure sans revérifier toutes les signatures cryptographiques : pratique pour un passage fréquent, à compléter par un check complet périodique. Intégrez cette vérification à votre routine : elle valide que les chunks chiffrés sont cohérents et restaurables, bien avant le jour où vous en aurez besoin.

Supprimer des snapshots et appliquer une rétention

Un dépôt qui ne fait que grossir devient ingérable. plakar sépare deux opérations qu'il faut bien distinguer : marquer des snapshots à supprimer (rm, prune), puis récupérer l'espace physiquement (maintenance). Cette séparation est une sécurité : rien n'est effacé tant que la maintenance n'a pas tourné.

Supprimer à la main avec un garde-fou

rm supprime des snapshots, mais en mode simulation par défaut : il affiche ce qu'il ferait sans rien toucher. Il faut ajouter -apply pour exécuter réellement.

plakar at /var/backups/repo rm 3a95e3f4

rm: would remove these 1 snapshot(s), run with -apply to proceed
2026-06-25T19:15:11Z   3a95e3f4   229 B   0s   /srv/www   tags=site-web

Vous pouvez cibler par âge (-before 30d), par tag (-tag daily) ou par identifiant. Ce dry-run par défaut évite les suppressions accidentelles : un réflexe de conception bienvenu sur un outil de sauvegarde.

Définir une politique de rétention

Pour automatiser, on décrit une politique nommée, puis on l'applique avec prune. plakar gère des politiques de type grand-père / père / fils (GFS) : garder N sauvegardes par jour, par semaine, par mois.

Créer la politique et définir ses règles :

plakar at /var/backups/repo policy add quotidien
plakar at /var/backups/repo policy set quotidien since='30 days' per-day=7 per-week=4

Vérifier ce qu'elle contient :

plakar at /var/backups/repo policy show quotidien

quotidien:
    filters:
        since: 2026-05-27T08:58:03+02:00
    periods:
        day:
            cap: 7
        week:
            cap: 4

Appliquer la politique avec prune (toujours en simulation par défaut) :

plakar at /var/backups/repo prune -policy quotidien

prune: would keep 2 and delete 0 snapshot(s), run with -apply to proceed
keep   27d4028b   /srv/www   match=day:2026-06-26 rank=1 cap=7
keep   3a95e3f4   /srv/www   match=day:2026-06-26 rank=2 cap=7

La sortie explique pourquoi chaque snapshot est conservé (match, rank, cap) : on voit le raisonnement de la politique avant de lancer la suppression avec -apply.

Récupérer l'espace disque

Marquer un snapshot ne libère pas l'espace : les chunks restent tant qu'ils peuvent être référencés. La commande maintenance fait le ménage réel, en supprimant les packfiles devenus orphelins :

plakar at /var/backups/repo maintenance

maintenance: Coloured 0 packfiles (0 orphaned) for deletion
maintenance: 0 blobs and 0 packfiles were removed

Répliquer hors site : la règle 3-2-1

Une sauvegarde sur la même machine que les données ne protège pas d'un sinistre. La règle 3-2-1 (trois copies, deux supports, une hors site) impose une copie distante. plakar la matérialise avec sync, qui réplique entre deux dépôts Kloset, y compris vers un stockage objet (S3) ou SFTP.

On enregistre d'abord la destination distante sous un label réutilisable, puis on synchronise :

plakar store add distant s3://mon-bucket-backups/klosets
plakar at /var/backups/repo sync to @distant

sync fonctionne dans trois directions : to pousse vers le dépôt distant, from tire depuis lui (utile pour reconstruire après un sinistre) et with synchronise dans les deux sens. La commande server expose, à l'inverse, un dépôt sur le réseau (localhost:9876 par défaut, suppression désactivée sauf -allow-delete) pour que d'autres machines y répliquent.

Pour le côté stockage objet de la chaîne, ces guides complètent la mise en place :

MinIO : stockage objet S3 auto-hébergé Une cible S3 que vous hébergez pour vos dépôts plakar.

Garage : stockage objet léger et géo-distribué Alternative légère et multi-zone pour des sauvegardes hors site.

Sauvegardes : RPO, RTO et règle 3-2-1 Concevoir une stratégie de sauvegarde et un plan de reprise.

Connecteurs : sauvegarder des bases de données et plus

plakar ne sauvegarde pas que des dossiers. Des connecteurs (intégrations) permettent de capturer des sources variées et de les écrire vers différentes destinations. La commande pkg show -available liste les intégrations publiées :

plakar pkg show -available

postgresql@v1.1.0-beta.8
mysql@v1.1.0-beta.4
etcd@v1.1.0-beta.4
k8s@v1.1.0
s3@v1.1.2
sftp@v1.1.3
proxmox@v1.1.0-rc.1
sqlite@v1.1.0-beta.2
rclone@v1.0.0-beta.9

On distingue trois familles, chacune avec sa commande de configuration :

Famille	Rôle	Commande
source	ce que l'on sauvegarde (importer)	`plakar source add <nom> <location>`
destination	où l'on restaure (exporter)	`plakar destination add <nom> <location>`
store	le backend de stockage du dépôt	`plakar store add <nom> <location>`

Un détail pratique : plakar source import -rclone réutilise une configuration rclone existante, ce qui ouvre la sauvegarde vers des dizaines de fournisseurs cloud sans tout reconfigurer. Plusieurs connecteurs portent encore une étiquette beta : épinglez les versions et testez avant la production. Pour les bases de données, ces guides détaillent la stratégie de dump et de restauration testée :

Sauvegarder et restaurer PostgreSQL pg_dump, pg_basebackup et restauration Point-In-Time.

Sauvegarder et restaurer MySQL mysqldump, binlog et restauration PITR.

Sauvegarder et restaurer Kubernetes Protéger l'état d'un cluster et ses volumes.

Archives autonomes : ptar et archive

Parfois, on veut une archive figée plutôt qu'un dépôt vivant : pour transporter des données, les déposer en cold storage ou les transmettre. plakar propose deux formats.

La commande archive exporte un snapshot vers une archive classique (tar, tarball pour tar.gz), lisible par n'importe quel outil :

plakar at /var/backups/repo archive -format tarball -output site-export.tar.gz 27d4028b

La commande ptar crée une archive Kloset autonome au format .ptar : un fichier unique dédupliqué, compressé et chiffré, qui embarque sa propre structure :

plakar ptar -o site.ptar /srv/www

b4652300: OK ✓ /srv/www/conf/nginx.conf
b4652300: OK ✓ /srv/www/html/index.html

Le .ptar conserve les bénéfices de Kloset dans un objet transportable, au prix d'une dépendance à plakar pour le relire (un tar.gz reste lisible partout). Choisissez selon le besoin : archive pour la portabilité maximale, ptar pour garder chiffrement et déduplication.

Sécurité : ce que plakar protège, et ce qu'il ne protège pas

plakar chiffre vos données au repos et vérifie leur intégrité, mais une stratégie de sauvegarde ne se résume pas à l'outil. Trois points méritent une attention opérationnelle.

D'abord, plakar seul ne protège pas d'un rançongiciel. Si un attaquant obtient les droits d'écriture sur le dépôt distant, il peut le supprimer. La parade est l'immuabilité côté stockage : activez l'Object Lock S3 (ou le verrouillage équivalent) et utilisez un compte de stockage séparé des machines sauvegardées. Méfiez-vous toutefois du mode compliance : des données verrouillées pour deux ans vous seront facturées pendant deux ans, sans suppression possible.

Ensuite, l'alerting existe mais passe par un service hébergé : après plakar login, plakar service enable alerting envoie un email en cas d'échec et publie les rapports dans le dashboard. C'est opt-in et désactivé par défaut ; gardez en tête que ces services transmettent des métadonnées opérationnelles à la plateforme de l'éditeur, ce qui peut compter selon vos contraintes de souveraineté.

Enfin, rappelez-vous la règle d'or déjà énoncée : la passphrase est irrécupérable. Une sauvegarde chiffrée dont la clé est perdue équivaut à une absence de sauvegarde.

Maturité, limites et alternatives

plakar est un projet jeune mais sérieux. Ses auteurs viennent de l'OpenSMTPD (Gilles Chehade, alias poolpOrg), gage de rigueur sur le code système, et la cryptographie a été auditée par un spécialiste reconnu. La version 1.1.3 est annoncée stable, avec des restaurations nettement plus rapides et une empreinte mémoire réduite sur gros volumes par rapport à la 1.0.

Il faut rester lucide pour autant. Les retours d'expérience en production publics restent rares comparés à restic ou borg, qui cumulent des années de recul. Plusieurs connecteurs de bases de données sont encore en beta. La récupération d'espace ne compacte pas les packfiles partiellement utilisés. Et la coexistence de deux modèles (dépôt Kloset vivant et archive ptar) peut dérouter au premier abord. Bonnes pratiques : épinglez les versions, testez vos restaurations après chaque montée de version, et surveillez la mémoire sur les dépôts distants volumineux.

Face aux alternatives, le positionnement est honnête plus qu'écrasant :

Outil	Point fort principal
plakar	découpage CDC rapide, déduplication avant chiffrement, interface web et API
restic	écosystème mûr, support S3 éprouvé, large communauté
borg	sobriété mémoire, restaurations locales complètes efficaces
kopia	pipeline cloud parallèle, interface web maintenue

À retenir

plakar prend des snapshots chiffrés et dédupliqués, avec une CLI plakar at <dépôt> <commande>
Le moteur Kloset combine fastcdc, BLAKE3, AES-256-GCM-SIV et Argon2id, avec déduplication avant chiffrement
Le dépôt est chiffré par défaut : la passphrase est critique, sa perte est définitive
On navigue sans tout restaurer : cat, diff, locate, mount (FUSE) et le dashboard web plakar ui
La rétention sépare le marquage (rm, prune + policy GFS, en dry-run par défaut) de la récupération d'espace (maintenance)
sync matérialise le hors-site de la règle 3-2-1 (directions to/from/with)
Vérifiez régulièrement (check) et testez vos restaurations : une sauvegarde non testée ne compte pas

Prochaines étapes

Sauvegarder avec restic L'autre référence de la sauvegarde chiffrée et dédupliquée, à comparer.

Synchroniser avec rclone Réutilisable comme source plakar via l'import de configuration rclone.

Le stockage objet avec s3cmd Manipuler le stockage objet vers lequel plakar réplique vos dépôts.

Sauvegarder avec tar L'approche archive classique, à mettre en regard de ptar.

Comprendre le stockage distribué Objet, fichiers, blocs : choisir le bon support pour vos sauvegardes.

Gérer l'espace disque Surveiller l'espace que consomment vos dépôts de sauvegarde.