MinIO, tout le monde ou presque connaît car c'est LE truc quand on veut du stockage objet S3-compatible auto-hébergé sous Linux. Sauf que voilà... la licence AGPL, ça pique pour pas mal de boîtes qui ne veulent pas se retrouver à devoir ouvrir leur code.

Du coup, y'a un nouveau projet qui débarque dans le tiek et qui devrait en intéresser plus d'un. C'est RustFS , codé en Rust (comme le nom le laisse deviner mes petits Sherlock) et 100% compatible S3. En gros, vous prenez votre stack MinIO existante, vous remplacez par ce truc, et en fait tout continue de fonctionner pareil... Vos buckets, vos applis, vos scripts Python, boto3... tout pareil !

docker run -d -p 9000:9000 -p 9001:9001 -v $(pwd)/data:/data -v $(pwd)/logs:/logs rustfs/rustfs:latest

Bon, on va pas se mentir, j’étais pas parti pour l’écrire cet article. Mais faut dire que j’ai un peu merdé dans les grandes largeurs pour le live, donc bon, sachant qu’en plus je traite d’un angle particulier de l’usage de ce cher Plakar, autant en faire un billet, ça sera le premier (et j’espère pas le seul) de 2026. On y croit ?

Plakar est une solution développée en France par une petite équipe apparemment friande des jeux de mots, puisqu’au delà de son nom même, le site est hébergé par la société Kandbaz. Voilà voilà…

Des confrères blogueurs ont déjà fait quelques présentations de l’outil (exemple: Adrien), principalement pour s’en servir sous Linux. Il se trouve que j’ai une machine Windows qui a besoin d’être sauvegardée, en vue d’une mise à jour de firmware de SSD qui devrait bien se passer, mais on doit toujours faire une sauvegarde avant de faire ce genre de choses. Mieux vaut prévenir que guérir comme on dit. Et la présentation en live aurait du se passer plus ou moins tranquille, mais bon, j’ai pas percuté la micro-coupure pendant plus d’une heure (habitué à ne pas avoir d’activité dans le chat), donc, je vous remet le processus sur « papier numérique ».

Je ne redétaille pas l’installation de Garage parce qu’on l’a faite en live sans souci.

Petit rappel rapide des caractéristiques de l’outil

On a donc un outil principalement en ligne de commande, qui repose sur un concept voisin de celui de Borg, qui nécessite la configuration d’un dépôt et propose un chiffrement natif des sauvegardes. Ce dépôt, local ou distant, peut être contacté de différentes manières, natives (SFTP/SSH) ou via des intégrations supplémentaires à installer au besoin. C’est le cas notamment du support S3.

Le setup

En soit, c’est très bien documenté : une fois l’outil installé, vous ajoutez le package directement, mais vous tombez sur un mur que je n’aime pas : créer un compte Plakar pour accéder aux intégrations. J’ai une petite idée de pourquoi ça peut avoir du sens (les intégrations concernent en général des solutions d’entreprise), mais ça me gonfle plus que profondément quand ça concerne des particuliers, qui se font déjà violer en permanence, donc pas la peine d’en rajouter (on a la même avec  BitWarden, ou El Gato et son Stream Deck Marketplace pour l’intégration… d’OBS, qui est pourtant mis en avant comme native – c’est donc faux). Fort heureusement, l’outil propose de builder l’intégration depuis les sources qui sont disponibles sur Github, comme le reste des sources de l’outil, et ça sans création de compte. C’est facile… si on est sous Linux.

J’avoue que pour l’instant les installations sont un peu brutes de décoffrage, mais le support Windows est vraiment frais, donc je ne vais pas trop me formaliser là-dessus. Le fait que ça doit déjà proposé pour une version 1.0 est déjà assez cool. Par contre, concernant la compilation des intégrations, c’est plus ardu : il faut disposer de Go (dans la version qui est demandée par Plakar), de Make (à priori à part Chocolatey pas de moyen indépendant), et peut-être d’autres outils, mais je me suis heurté à un mur à cause de ça. La solution, comme d’hab’, aura demandé un pas de côté.

La cross compilation à la rescousse

Une des particularités de Go, c’est qu’on peut nativement compiler pour un autre système d’exploitation que celui sur lequel on se trouve. Et la chaine de compilation nécessaire est plus facile à déployer sous Linux; ça tombe bien, WSL est là pour ça. Après l’installation de la même version de Plakar que sous Windows, j’ai donc installé build-essential (pour être sûr d’avoir un max d’outils, donc Make), installé la version 1.24.12 de Go via asdf-vm (je vous renvoie vers la doc de Stéphane Robert qui a tout expliqué au sujet de cet outil trop pratique). Et pour la compilation d’un autre OS, c’est simple : on configure une variable d’environnement, GOOS, éventuellement l’architecture (oui, parce que c’est aussi possible), l’extension de fichier dans la variable EXT (parce que sous Windows, il faut un .exe pour qu’il soit exécutable – oui c’est débile en 2026, mais que voulez-vous, l’IA c’est plus intéressant à intégrer que moderniser un OS don personne ne voulait à la base) et on lance la compilation de l’intégration via la commande plakar ad-hoc. Vraiment, c’est aussi simple que ça :

$ export GOOS=windows
$ export EXT=.exe
$ plakar pkg build s3
info: fetching https://plugins.plakar.io/kloset/recipe/v1.0.0/s3.yaml
/usr/bin/make -C /tmp/build-s3-v1.0.7-161840773 EXT=.exe
3fe849cb: OK ✓ /manifest.yaml
3fe849cb: OK ✓ /s3Importer.exe
3fe849cb: OK ✓ /s3Exporter.exe
3fe849cb: OK ✓ /s3Storage.exe
3fe849cb: OK ✓ /
Plugin created successfully: s3_v1.0.7_windows_amd64.ptar
$ ls -l
.rw------- 1 42M seboss666 16 Jan 22:29  s3_v1.0.7_windows_amd64.ptar

On peut donc désormais copier le fichier ptar sous Windows (il faudra que je creuse ce format qui semble un peu maison), et on peut l’installer avec la bonne commande :

> .\plakar.exe pkg add ./s3_v1.0.7_windows_amd64.ptar
> .\plakar.exe pkg list
s3@v1.0.7

La sauvegarde ? Ben ça fonctionne

On peut donc attaquer le dur. J’ai juste suivi la doc de l’intégration, à savoir créer le kloset l’initialiser, et lancer le backup d’un dossier vers ce kloset là :

.\plakar.exe store add garage s3://192.168.1.201:3900/backup-pc access_key=<accesskey> secret_access_key=<secret_key> use_tls=false
.\plakar.exe at "@garage" create
repository passphrase:
repository passphrase (confirm):
.\plakar.exe at "@garage" ls
repository passphrase:
.\plakar.exe at "@garage" backup C:\\Users\\Seboss666\\Pictures\\blog
repository passphrase:
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/Firefox_groupe_onglets.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/Firefox_profils.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/docker-docker-everywhere.jpg
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/418-error-page.png
e363f7fa: OK ✓ /C:/Users/Seboss666/Pictures/blog/cross.svg
(...)
.\plakar.exe at "@garage" ls
repository passphrase:
2026-01-16T21:40:31Z e363f7fa 42 MiB 0s /C:/Users/Seboss666/Pictures/blog

Bonus, on peut vérifier l’état du backup depuis un autre PC, ou un autre OS, donc je suis retourné sur WSL, j’ai viré les variables d’environnement pour builder l’intégration pour Linux cette fois, et rebuildé/ajouté l’intégration. On reprend ensuite la même commande pour ajouter le Kloset, mais pas besoin de l’initialiser, on peut directement lister son contenu en fournissant la bonne passphrase :

$ plakar store add garage s3://192.168.1.201:3900/backup-pc access_key=<access_key> secret_access_key=<secret_key>
$ plakar at "@garage" ls
repository passphrase:
2026-01-16T21:40:31Z e363f7fa 42 MiB 0s /C:/Users/Seboss666/Pictures/blog

On peut donc faire à peu près ce qu’on veut dès lors : restauration complète ou partielle, création de nouveaux backups, etc.

Verdict

Donc oui, tout a fonctionné pratiquement du premier coup. J’ai quand même tâtonné au départ concernant le build de l’intégration, à vouloir « make » direct à partir du dépôt git. Mais dans ce cas, on se retrouve avec les trois binaires, sans infos sur la construction du fameux ptar (on est là encore dans le simili-jeu de mots, vraiment…), ce qui est plutôt dommage. Il m’aura fallu quelques minutes pour me résigner à utiliser plakar directement. Il faudrait aussi un peu plus de retour sur les commandes qui se déroulent bien (sans erreur). Autant quand on se plante, on le sait, mais quand on se plante pas, voir juste un retour à la ligne est un peu frustrant et déroutant.

Il y a question aussi sur les performances de la sauvegarde testée. j’ai testé sur un dossier de 108 images, et un des développeurs s’est étonné sur BlueSky du temps que ça a pris. J’avoue que pour l’instant, je n’ai pas creusé le sujet, il y a des chances que ça soit dû aux performances S3 elle-mêmes, à NTFS, une combinaison de tout ça. Garage est censé être performant, mais bon, on est sur un processeur ARM assez poussif quand même, qui doit déjà gérer le transfert réseau, donc on est pas à l’abri que ça soit un problème purement chez moi.

En tout cas, pour un jeune logiciel, la qualité de la documentation et l’implémentation Windows déjà opérationnelle (même si encore un peu buggée chez certains, en lien notamment avec les différences slash/antislash à cause de Windows), en bonus une interface web pour parcourir les backups, il m’a très agréablement surpris. On ne peut souhaiter que ça mature comme il faut et que l’entreprise trouve son équilibre (la stabilité financière et l’open-source, hein…). Et moi que je regarde d’un peu plus près le statut du live la prochaine fois (ou que je configure l’enregistrement en plus du stream)…