ArkVault : Une interface graphique pour BorgBackup qui permet à votre disque de reconstruire complètement votre système Linux

Branchez un disque de sauvegarde sur une installation Linux vierge, sans aucune configuration préalable, et vous récupérerez bien plus que simplement vos fichiers. ArkVault écrit un kit de restauration guidé sur le disque, à côté de la sauvegarde chiffrée ; ainsi, le disque lui-même sait comment reconstruire la machine : fichiers de configuration, clés SSH, liens symboliques de lancement, unités systemd, etc.

Résultat final

Ces captures d’écran proviennent d’une exécution en environnement isolé avec des données fictives ; il ne s’agit pas de la liste des fichiers de ma machine réelle.

Quatre profils, des estimations de taille en temps réel, et un icône de verrou sur chaque profil contenant des éléments marqués comme sensibles, tels que les clés SSH. Un seul bouton permet de sauvegarder tout ce que vous avez sélectionné.

C’est là l’objectif principal du logiciel : l’assistant de restauration lit le fichier install-map depuis le disque et affiche précisément tout ce qui a été sauvegardé, regroupé et pouvant être sélectionné ; un icône de verrou indique les éléments sensibles.

Il existe également un mode glisser-déposer pour créer rapidement des collections ponctuelles qui ne font pas partie du catalogue principal.

Métrique	Valeur
Code	Environ 7 900 lignes de Python, 50 fichiers dans l’archive ZIP
Dépendances Pip	Aucune. GTK est fourni par le système ; le fichier requirements.txt est volontairement vide
Suite de tests	93 tests sur 93 réussis ; aucun besoin de pytest
Taille de l’archive ZIP	116 Ko (le binaire Borg n’est pas inclus ; l’installateur le télécharge)
Test de restauration en environnement isolé	Les 8 éléments ont été restaurés correctement dans un $HOME tout neuf, en une seconde
Durée d’exécution nocturne sur ma machine	De 51 secondes à 1 minute 31 seconde (du 3 au 15 septembre 2026)
Nombre d’éléments sauvegardés par nuit	222 à 225 (du 11 au 16 septembre 2026)
Dédoublonnage, dans mon dépôt	188,45 Go de snapshots stockés sur seulement 18,24 Go (9 septembre 2026)
Licence	MIT, gratuit

Ce que Borg vous offre en réalité

ArkVault n’est pas un moteur de sauvegarde à part entière. Il s’agit d’une interface frontale pour BorgBackup, qui se charge des tâches complexes :

• Chiffrement : repokey-blake2. La clé de chiffrement se trouve dans le dépôt, protégée par votre phrase de passe. Quiconque vole le disque ne récupérera rien.
• Dédoublonnage : découpage du contenu en blocs, de sorte que dix snapshots d’un répertoire domestique évoluant lentement ne nécessitent pas dix fois plus d’espace de stockage.
• Compression : utilisation de zstd au niveau 6. Une compression efficace sans ralentir excessivement le processus de sauvegarde.
• Rétention : borg prune conserve par défaut 7 snapshots quotidiens, 4 hebdomadaires et 6 mensuels (paramètres modifiables), permettant ainsi aux anciens snapshots d’être supprimés et d’éviter de remplir le disque.

Pourquoi une distribution immuable a imposé un design différent

J’ai développé cela sur Bazzite, une distribution Fedora atomique et immuable dont le système de fichiers racine est en lecture seule. Par la suite, j’ai migré vers Bluefin, qui présente les mêmes contraintes. Ces contraintes ont influencé la conception complète de l’outil :

• Tout s’installe dans ~/.local. Rien ne touche à /.
• Le venv est créé avec l’option --system-site-packages, de sorte que GTK4/PyGObject provient directement du système hôte, sans avoir à compiler de bindings sur une base en lecture seule.
• L’instruction pip install borgbackup ne fonctionne pas ici (pas d’en-têtes liblz4, pas de paquets précompilés adaptés) ; c’est pourquoi l’installateur télécharge le binaire Borg autonome fourni par les développeurs, une version générée via PyInstaller incluant FUSE.
• Aucune utilisation de sudo. L’unique opération nécessitant des droits administrateur, à savoir le formatage d’un disque, se fait via une invite polkit/pkexec.

L’idée en soi : le disque reconstruit la machine

Borg ne sait pas quels fichiers sont importants, quelles permissions ils nécessitent, ni ce qu’il faut faire après leur installation pour que la machine fonctionne à nouveau. Les outils de sauvegarde classiques vous restituent simplement les fichiers ; il vous reste alors à vous souvenir de l’emplacement de chacun d’eux et des unités systemd à réactiver. ArkVault, quant à lui, enregistre ces informations sur le disque lors de chaque sauvegarde :

• arkvault-repo/ : le dépôt Borg chiffré.
• ArkVault-App/ : une copie autonome d’ArkVault, incluant le code source et l’installeur ; cette copie est créée de manière atomique (dans un répertoire temporaire, puis renommée), de sorte qu’une copie interrompue ne laisse jamais d’application incomplète sur le disque.
• arkvault-install-map.json ainsi que RESTORE-README.md : un manifeste de tout ce qui a été sauvegardé, ainsi qu’un guide en texte brut que l’on peut lire sans aucun outil particulier.

Le fichier d’installation indique quels éléments sont secrets ; il ne contient cependant jamais leurs contenus.

Ce qu’effectue réellement une exécution de sauvegarde

Une exécution de sauvegarde se déroule en plusieurs étapes simples : identifier ce que le catalogue correspond à (les chemins manquants sont simplement ignorés), mettre éventuellement en pause les services fortement sollicités en écriture afin que les bases de données restent cohérentes, exécuter borg create et borg prune, puis enfin écrire le kit de restauration sur le disque.

La deuxième copie : un miroir de dossiers classiques

Un dépôt Borg est dédupliqué, chiffré et opaque. Pour le lire, il faut Borg ou ArkVault ; ce qui convient tant qu’on dispose de l’un ou l’autre sur la machine concernée.

Il existe donc un second mode, arkvault mirror, qui écrit simplement des dossiers relatifs à $HOME sur le disque. Pour restaurer les données, on utilise bash <drive>/restore.sh, ou on déplace manuellement les dossiers. On obtient ainsi une copie actuelle, sans historique ni déduplication.

Deux éléments empêchent l’approche « il suffit de copier les dossiers » d’être naïve :

• Les secrets restent chiffrés. Le format exFAT ne gère pas les permissions Unix ; ainsi, un dossier .ssh copié serait accessible à tous. Chaque élément marqué comme secret est au contraire placé dans un fichier tar chiffré via GPG (le format tar conserve les permissions que le système de fichiers ne peut pas gérer). Le script restore.sh le déchiffre puis réapplique les permissions lors de la restauration.
• exFAT ne tient pas compte de la casse. Un arborescence contenant à la fois Foo/ et foo/ se retrouve fusionnée lors de la copie, ce qui équivaut à une perte de données mais ressemble à un succès. ArkVault détecte à l’avance les conflits de casse ainsi que les caractères interdits, et stocke ces arborescences sans perte sous forme de fichiers .tar.gz, en indiquant la raison dans le manifeste.

Les deux modes écrivent le même kit de restauration sur le disque ; ainsi, l’un ou l’autre fournit au prochain ordinateur les informations nécessaires pour restaurer les données.

Les mécanismes de sécurité

La plupart des efforts ont été consacrés à ces protections :

• Le contrôle du format bloque le disque système. Formater le mauvais disque est un désastre classique avec les outils de sauvegarde. ArkVault détermine les disques physiques en parcourant /sys/class/block/*/slaves, car le nom du périphérique mapper d’un système chiffré ne ressemble en rien au nom du disque sous-jacent ; ainsi, les vérifications basiques sur les noms échouent. S’il ne parvient pas à identifier les disques système, il échoue de manière sécurisée et refuse de formater quoi que ce soit. Il faut toutefois saisir manuellement le nom exact du périphérique pour confirmer.
• Contrôle des chemins lors de la restauration. Un fichier de configuration corrompu ou modifié ne peut pas écrire en dehors du répertoire cible : les liens symboliques sont résolus, mais le lien final n’est pas suivi volontairement ; toute tentative de restauration hors du répertoire home est bloquée.
• Protection des données secrètes dans les journaux. Le mot de passe ainsi que tout contenu identifié comme secret sont supprimés grâce à une recherche textuelle exacte et à des expressions régulières couvrant des motifs tels que apiKey: et Bearer.
• La feuille de récupération. Lors de la première sauvegarde, une feuille contenant le mot de passe s’affiche, avec un texte non sélectionnable afin d’éviter toute copie accidentelle ; le bouton de fermeture reste désactivé tant que vous ne cochez pas « J’ai enregistré mon mot de passe ». Cette feuille n’est jamais écrite sur le disque. Si vous perdez ce mot de passe, la sauvegarde devient définitivement inaccessible.
• Le format FAT32 est interdit comme cible de sauvegarde car sa limite de 4 Go par fichier pose problème à Borg. L’exFAT est autorisé, mais avec un avertissement, puisque Borg stocke lui-même les métadonnées Unix.
• Les archives vides sont refusées. Si aucun fichier n’est présent dans les chemins sources (disque démonté, erreur de saisie), ArkVault refuse de créer une archive vide qui pourrait être interprétée à tort comme une réussite.
• La vérification est entièrement sous votre contrôle. borg check peut être lancé via l’interface ou la ligne de commande pour effectuer une vérification d’intégrité ; « Parcourir le snapshot » permet de monter l’archive en lecture seule via FUSE afin de l’inspecter avant de lui faire confiance.

Configuration

Il vous faut les bindings PyGObject pour GTK4/libadwaita, ainsi que udisks2 et polkit. Ceux-ci sont déjà présents sur Fedora/GNOME ; sur Debian/Ubuntu, il suffit d’exécuter une seule commande :

sudo apt install python3-gi gir1.2-gtk-4.0 gir1.2-adw-1

Ensuite, lancez l’installateur, qui est idempotent et peut être réexécuté en toute sécurité :

bash install.sh

Celui-ci copie l’application dans ~/.local/share/arkvault, crée un environnement virtuel --system-site-packages, télécharge le binaire officiel de Borg, puis place ~/.local/bin/arkvault ainsi qu’une entrée pour le bureau. Ensuite :

arkvault probe

Tout devrait indiquer « OK ». La commande arkvault lance l’interface graphique ; le même noyau gère également une interface en ligne de commande sans interface graphique.

arkvault probe|backup|restore|list|check

L’étape cruciale : modifier le catalogue. Celui fourni par défaut n’est qu’un exemple générique. Les fichiers core/discovery.py, profiles.py, core/quiesce.py, core/containers.py et core/installmap.py contiennent tous des sections marquées « EDIT ME ». Il s’agit en fait de dresser une liste précise des éléments qu’une installation neuve ne peut pas restaurer ; personne ne peut le faire à votre place.

Le catalogue lui-même est simplement du code Python, situé dans core/discovery.py. Chaque entrée correspond à un chemin relatif à votre dossier personnel, à un indicateur relatif aux secrets et à une note explicative. Les chemins sont vérifiés au moment de l’exécution ; donc il n’y a aucun risque à lister quelque chose que vous ne possédez pas. Voici la liste par défaut :

_SETTINGS = [
    (".bashrc", False, "Bash rc"),
    (".gitconfig", False, "Git identity and settings"),
    (".ssh", True, "SSH keys/config/known_hosts (PRIVATE KEYS)"),
    (".config/rclone", True, "rclone remotes (may embed tokens)"),
]

Les applications installées dans votre dossier personnel peuvent également inclure des étapes de réinstallation que le wizard de restauration reproduit ou ajoute à la liste manuelle des actions à effectuer. Le même fichier contient un exemple commenté pour une application Node.js :

redeploy = {"steps": [
    {"kind": "npm", "dir": "my-node-app", "cmd": "npm ci"},
    {"kind": "symlink", "link": ".local/bin/my-app",
     "target": "my-node-app/cli.js"},
    {"kind": "desktop-entry",
     "path": ".local/share/applications/my-app.desktop"},
    {"kind": "privileged-script", "script": "my-node-app/install.sh",
     "via": "pkexec", "manual": True,
     "desc": "Installs udev rules / system units (needs root)"},
]}

J’ai retiré quelques fichiers d’initialisation shell de la première liste. La version fournie dans le zip inclut également une étape de création d’environnement virtuel Python ("kind": "pip").

Lancez alors la première sauvegarde, enregistrez la feuille de récupération ailleurs que sur le disque de sauvegarde, puis cliquez sur « Copier l’application sur le disque ». Pour des exécutions automatiques, un modèle de minuteur systemd est disponible dans README-SETUP ; celui-ci lit la phrase de passe depuis le trousseau ou via la variable d’environnement ARKVAULT_PASSPHRASE.

L’exercice de restauration (sandbox)

Je n’ai pas encore restauré ma machine réelle à partir de ce disque. Ce que j’ai fait, c’est un exercice complet dans un environnement sandbox, sur un $HOME fictif, en utilisant exactement la même arborescence que dans le fichier zip :

1. Dézippage du fichier source, exécution de install.sh : téléchargement effectif de 27,9 Mo via Borg.
2. arkvault probe : tout est OK.
3. arkvault backup de 3 profils d’exemple dans un répertoire temporaire : 8 éléments sauvegardés ; le dépôt a été initialisé avec repokey-blake2, ainsi que install-map, RESTORE-README et le self-bundle.
4. arkvault list, puis arkvault check : les tests ont réussi.
5. arkvault restore dans un deuxième répertoire home vierge : les 8 éléments se sont retrouvés aux bons emplacements ; une liste de vérification manuelle a également été générée pour le reste.

La suite de tests, qui ne nécessite aucune dépendance, obtient 93/93 sur la même arborescence. Cela prouve que le mécanisme fonctionne avec des données d’exemple. Cela ne prouve cependant pas qu’il puisse restaurer un répertoire home réel et volumineux.

Chiffres provenant de ma propre machine

Le même outil effectue une sauvegarde de ma propre machine chaque nuit à 02:00, grâce à un minuteur utilisateur de systemd. Ces chiffres proviennent du journal de cette unité ainsi que de la sortie --stats de Borg lui-même :

Quoi	Valeur
Éléments capturés par exécution	222–225 (11–16 septembre 2026)
Bases de données SQLite sauvegardées en premier	27–39 par exécution, 1,4–1,7 Go (11–16 septembre 2026)
Une seule sauvegarde (9 septembre 2026)	17,45 Go en taille originale, 14,12 Go après compression, 1,62 Go après suppression des doublons
Toutes les sauvegardes (9 septembre 2026)	188,45 Go en taille originale, 146,78 Go après compression, 18,24 Go après suppression des doublons (environ 10× de réduction)
Taille du dépôt sur le disque (16 septembre 2026)	31 Go
Durée d’exécution nocturne, 3–15 septembre 2026	51 s à 1 min 31 s
Durée d’exécution nocturne, 16 septembre 2026	3 min 8 s
Pic de mémoire utilisée	1,7–2,6 Go (3–16 septembre 2026)

Chaque nuit, seuls 0,85 à 1,6 Go de nouvelles données sont ajoutés au dépôt ; c’est pourquoi les snapshots quotidiens d’un jeu de données source de 15 à 18 Go restent peu coûteux. Je n’ai pas encore identifié la raison pour laquelle l’exécution du 16 septembre a duré trois fois plus longtemps que d’habitude. L’écart entre les 18 Go indiqués par Borg le 9 septembre et les 31 Go effectivement présents sur le disque une semaine plus tard s’explique par deux facteurs que je peux nommer mais que je n’ai pas mesurés séparément : sept nuits supplémentaires de nouvelles données, ainsi que des snapshots supprimés dont l’espace n’a jamais été récupéré par Borg. En effet, Borg ne libère l’espace du dépôt qu’après exécution de la commande borg compact, et ArkVault ne lance jamais cette commande. Lors des trois nuits où ces statistiques ont été enregistrées, Borg s’est terminé avec des avertissements (code de sortie 100). ArkVault considère cela comme un avertissement, et non comme un succès complet.

Pièges à éviter

• L’archive zip corrige un bug présent dans le script d’installation original. Les versions publiées sur GitHub par Borg incluent une signature GPG .asc mais pas de fichier .sha256 ; par conséquent, la récupération du checksum échouait avec un code 404, et l’instruction set -e interrompait l’installation avant que la procédure de secours prévue dans le script ne puisse s’exécuter. Ce problème est désormais résolu ; il existe également une variable d’environnement optionnelle ARKVAULT_BORG_SHA256 permettant de forcer l’utilisation d’un hash fiable. Sur ma propre machine, ce problème ne s’est jamais produit, car le binaire Borg était déjà présent, si bien que la partie du script chargée du téléchargement n’a jamais été exécutée.
• Le format FAT32 peut vous causer pas mal de soucis. ArkVault le détecte et refuse d’utiliser ce format ; toutefois, de nombreuses clés USB sont livrées en format FAT32 par défaut.
• La suppression des anciennes sauvegardes ne réduit pas automatiquement la taille du dépôt. ArkVault exécute borg prune après chaque sauvegarde, mais jamais borg compact. Or, dans la version actuelle de Borg (1.4.4 sur ma machine), l’espace libéré n’est réellement disponible qu’après exécution de borg compact. Il convient donc de lancer régulièrement cette commande sur le dépôt, ou d’ajouter cette étape à votre planification.
• Une exécution interrompue laisse un verrou actif sur le dépôt. L’instruction borg break-lock permet de le supprimer (il existe même un bouton dans l’interface graphique à cet effet). De plus, en configurant BORG_LOCK_WAIT=120, les exécutions simultanées attendront plutôt que de se terminer immédiatement en échec.
• Le mode WAL de SQLite requiert que les fichiers db, wal et shm soient sauvegardés ensemble ; sinon, il faut d’abord arrêter le service. C’est la raison d’être de l’étape de mise en veille. Le redémarrage du service se fait dans un bloc finally, de sorte que les services reprennent normalement même si la sauvegarde échoue en cours de route.
• La restauration vers un autre utilisateur fonctionne, car chaque destination est enregistrée par rapport au répertoire personnel. Les éléments dont l’appartenance ne peut être associée au nouvel utilisateur figurent dans une liste manuelle plutôt que d’être ignorés silencieusement.
• Absence de GNOME keyring (machine sans interface graphique, environnement CI) ? Dans ce cas, le système utilise un mot de passe en mémoire ainsi qu’une demande interactive au lieu de se bloquer.
• Le bug classique : auparavant, lancer python -m arkvault backup ... ne produisait aucun effet visible : le parseur d’arguments de l’interface graphique absorbait la sous-commande et renvoyait un code 0. Désormais, __main__.py gère explicitement les sous-commandes CLI. Vérifiez donc qu’une archive a bien été créée suite à l’exécution de la commande, et non simplement que le script renvoie un code 0.
• Les outils désinstallés restent répertoriés. Après avoir supprimé un outil, chaque exécution nocturne affichait un avertissement indiquant que son dossier était listé mais manquant. ArkVault poursuit la sauvegarde du reste et reproduit cet avertissement dans le résumé de l’opération. Pour corriger cela, il faut supprimer manuellement l’entrée correspondante de votre catalogue.
• Le catalogue fourni est volontairement vide. Celui que j’utilise personnellement liste précisément l’emplacement de mes données importantes ; or, ce type d’information ne doit absolument pas figurer dans une archive publique. Vous obtenez donc un exemple simple avec des répertoires Projects/Settings ainsi qu’un exemple de redéploiement fonctionnel (décrit ci-dessus dans la section « Mise en place ») : même structure, mais sans aucune référence à mes propres chemins d’accès.

Voir aussi : comment faire en sorte qu’un modèle de langage adapte n’importe quel projet à votre système et l’ensemble des composants sauvegardés par ArkVault. ArkVault a été conçu avec l’aide d’IA.

Téléchargements

• Download ArkVault source (zip) 116 KB

Gratuit pour un usage personnel. Si ça vous fait gagner un après-midi, le bouton café n'est pas loin.