Fonctionnalités

BombVault est simple par défaut et profond quand vous en avez besoin. L'interface ne montre que l'essentiel jusqu'à ce que vous basculiez le commutateur Vue simple / Vue avancée. Cette page regroupe l'ensemble des fonctionnalités.

Périmètre de sauvegarde

Les conteneurs, chacun avec son interrupteur de planification, son ordre de sauvegarde et son historique.

Quoi	Ce qui est enregistré
Conteneurs Docker	Le répertoire appdata plus la définition du conteneur (image, variables d'environnement, ports, labels, volumes). Par défaut, tout le répertoire appdata ; Choisir les dossiers sur le conteneur permet de cocher exactement les dossiers que couvre la sauvegarde, avec un décompte en direct des chemins, la liste de ce que vous avez laissé de côté et un interrupteur Ignorer les dossiers de cache par racine (CACHEDIR.TAG).
VMs KVM / libvirt	La ou les images disque de la VM, la définition XML et la NVRAM UEFI (arrêt propre ou instantané à chaud, via SSH). Les instantanés à chaud se rabattent automatiquement sur une sauvegarde propre si l'instantané ne peut pas être créé, de sorte qu'une sauvegarde de VM n'échoue jamais simplement. Avec Blocs modifiés uniquement activé, une VM en marche avec des disques qcow2 est lue grâce aux points de contrôle libvirt : une sauvegarde ne lit que les blocs écrits depuis la précédente, et chaque instantané restaure toujours le disque entier à lui seul. Les disques sur des zvols ZFS sont transmis avec zfs send par la même liaison SSH, de sorte qu'une VM dont les disques sont des zvols est sauvegardée comme une seule VM. L'état d'un vTPM en passthrough est enregistré à côté de la NVRAM lorsque le XML du domaine indique son chemin. Un vTPM émulé, que TrueNAS met en place pour les invités Windows 11, ne publie pas ce chemin : gardez donc à portée de main la clé de récupération d'un tel invité. Voir le guide de sauvegarde des VM.
Flash Unraid	Toute la clé USB flash (/boot) : OS, licence, config de la matrice, partages, réseau et config des plugins. La restauration est un téléchargement .zip en un clic et n'écrase jamais la flash active.
Configuration de l'application	Le propre /config de BombVault (base de réglages, identifiants hors site, paire de clés SSH libvirt), capturé avec VACUUM INTO de SQLite afin qu'une base en mode WAL ne soit jamais capturée en pleine écriture. Restauré via un auto-redémarrage, de sorte que la base active n'est jamais écrasée sous un handle ouvert.
Fichiers et dossiers	Des jeux de fichiers nommés : n'importe quel dossier du serveur (un partage, vos documents, une bibliothèque de photos), chacun avec des motifs d'exclusion optionnels par jeu. Parité complète avec les autres domaines (plannings, rétention, copie hors site, vérifications d'intégrité et essais de restauration).
Jeux de données ZFS	Un jeu de données avec tous ceux qui se trouvent en dessous, lu depuis un seul instantané ZFS pour qu'ils viennent tous du même instant, et stocké avec restic comme un dossier : dédupliqué, navigable, fichiers restaurables un par un. Les nouveaux jeux enfants s'ajoutent d'eux-mêmes, on peut en exclure un seul, et un jeu illisible est ignoré et nommé. En option, des conteneurs sont arrêtés ou une commande s'exécute juste le temps de l'instantané. Les volumes n'en font pas partie : le volume d'une VM est sauvegardé avec sa VM, un volume sans VM n'est pas encore sauvegardé. Voir Jeux de données ZFS.

Restauration

La récupération guidée fait passer une installation neuve par le cas catastrophe, au même endroit.

• Restauration complète en un clic. Choisissez un instantané, cliquez sur Restaurer. Terminé.
• Une chronologie par élément. Les conteneurs, VMs, jeux de fichiers, le flash et la configuration de l'application listent leurs sauvegardes comme une seule chronologie sur tous les endroits où elles se trouvent, le dépôt où elles sont écrites et chaque cible hors site. Une sauvegarde copiée hors site apparaît une fois, marquée avec chaque endroit. Les endroits hors site sont lus quand vous les ouvrez, et supprimer à un endroit dit si c'était la dernière copie.
• Les conteneurs sont automatiquement réinstallés. La définition du conteneur est rejouée contre l'API Docker, de sorte que le conteneur réapparaît dans l'onglet Docker d'Unraid exactement comme il était.
• Le GPU, les limites et les liens reviennent. Un conteneur restauré retrouve ses limites de ressources, son pilote de journaux, ses réglages DNS, ses anciens liens et son GPU ou runtime (--gpus, --runtime=nvidia). Sur un hôte sans ce pilote GPU ou ce runtime, la restauration le dit et propose Restaurer sans GPU ni runtime, aussi après la restauration de plusieurs conteneurs ou d'un stack. Un lien vers un conteneur absent, ou arrêté au démarrage du conteneur restauré, est laissé de côté, et l'historique des exécutions le signale.
• Les VMs sont automatiquement recréées. Le XML est réimporté via SSH afin que la VM réapparaisse dans le VM Manager avec son disque et sa NVRAM UEFI rattachés, même après la suppression de la VM. Découvrir les sauvegardes reconstruit une entrée entièrement disparue (par exemple après une réinstallation).
• Restauration individuelle. Restaurez un conteneur, une VM ou un jeu de fichiers sans toucher aux autres.
• La restauration flash est un téléchargement .zip. Elle est diffusée vers votre navigateur sous flash-<id>.zip, prête à déposer dans le créateur de clé USB Unraid. Le /boot actif n'est jamais touché.
• Un plugin à la fois. La page Flash liste les plugins de chaque sauvegarde du flash avec leur version et leur taille, et remet un seul plugin sur la clé en service : son fichier .plg, son dossier sous config/plugins et les fichiers de paquet que contient la sauvegarde. Rien d'autre ne change sur la clé. Unraid installe le plugin au prochain démarrage, ou tout de suite via Plugins, Install Plugin.
• Export zip flash planifié. Après chaque sauvegarde flash, écrivez éventuellement l'instantané sous forme de .zip simple dans un dossier de votre choix (un unique flash-latest.zip écrasé ou un historique glissant). Pointez-le vers un dossier Syncthing ou rclone pour que votre sauvegarde de clé USB amorçable quitte le serveur automatiquement.
• Vérification de conflit avant lancement. Avant que quoi que ce soit ne soit arrêté ou supprimé, la restauration vérifie que l'IP statique du conteneur et les ports hôtes publiés sont libres, et s'interrompt avec un message clair au lieu de laisser une restauration à moitié faite.
• Vérifications avant la restauration. Chaque dialogue de restauration vérifie d'abord que le dépôt répond, que la clé enregistrée l'ouvre, que le point de restauration existe et que la cible a de la place pour ce que la restauration écrit. Démarrer reste verrouillé tant qu'une vérification échoue, et le (i) du bouton indique laquelle.
• Plan de restauration. Avant votre confirmation, le dialogue montre ce que la restauration fait par rapport à l'état actuel : fichiers nouveaux, remplacés et inchangés, avec la liste sur demande, et les fichiers de la cible absents de la sauvegarde, qui restent en place. Pour les conteneurs et les VM, il compare aussi les paramètres recréés avec ceux en service : image et tag, ports, noms de variables et volumes, ou mémoire, vCPU, disques et réseau. restic le calcule par une simulation fondée sur la taille et la date de modification, sans lire les fichiers ; un très grand arbre s'arrête après 30 secondes et le signale. Une restauration de stack vérifie et planifie chaque membre et nomme celui qui la bloque.
• Dossiers partagés. Une restauration sur place nomme chaque autre conteneur, en marche ou non, dont un montage atteint un dossier qu'elle écrit, par exemple « ce chemin est aussi utilisé par nextcloud-db ». C'est un avertissement, rien n'est bloqué.
• Restauration au niveau fichier. Dépliez les Fichiers d'un instantané de conteneur, filtrez, cochez autant de fichiers et dossiers que vous voulez, puis restaurez la sélection sur place ou dans un dossier de votre choix.
• Restauration de jeu de fichiers. Restaurez un instantané de jeu de fichiers sur place (après une confirmation explicite) ou dans un dossier de votre choix, jamais en silence. La restauration sélective fonctionne aussi ici.
• Restauration d'un jeu de données ZFS. Restaurez un jeu de données d'un élément à sa place (après un instantané ZFS de sécurité qui reste jusqu'à ce que vous le supprimiez), dans un dossier ou seulement les fichiers choisis, ou tous les jeux d'une sauvegarde dans un dossier. Un jeu de données n'est jamais restauré par rollback ni remplacé.
• La restauration conserve l'état d'exécution. Un conteneur ou une VM en cours d'exécution au moment de la sauvegarde revient en cours d'exécution ; celui qui était arrêté reste arrêté. Cochez Laisser arrêté après restauration pour recréer sans démarrer.
• Restaurer toute une pile. Les conteneurs d'un même projet Docker Compose sont regroupés dans un panneau Stacks. Restaurer la stack… reconstruit chaque membre à partir de sa dernière sauvegarde en le laissant arrêté, puis les démarre éventuellement dans l'ordre depends_on.
• Progression en direct, annulation et retour d'occupation. Une restauration longue affiche une barre de pourcentage en direct et peut être annulée avec une confirmation adaptée au type. Une restauration annulée est enregistrée comme annulée, pas comme échouée.
• Récupération guidée. Un onglet Récupération dédié accompagne une installation neuve à travers le cas de sinistre. Voir Sauvegarde hors site et récupération.
• Restauration depuis un autre dépôt BombVault. Une session unique en lecture seule ouvre le dépôt d'une autre instance BombVault avec l'APP_KEY de cette instance, afin que vous puissiez tirer un conteneur du serveur A vers le serveur B sans toucher à vos propres réglages. Voir Sauvegarde hors site et récupération.
• Les propriétés ZFS reviennent. Chaque sauvegarde ZFS garde les propriétés définies localement de chaque jeu de données, comme la compression, la taille d'enregistrement, le quota et la sensibilité à la casse. Une restauration dans un nouveau jeu de données le crée avec elles, et une restauration dans un jeu de données existant les affiche et ne les applique que si vous le demandez. Voir Jeux de données ZFS.
• Importer depuis le plugin Appdata.Backup. Sur la page Récupération, indiquez à BombVault le dossier de sauvegarde du plugin. Chaque archive de conteneur devient un point de restauration de son conteneur, daté du moment où le plugin l'a créée. Les archives déjà importées sont ignorées, et les archives elles-mêmes sont seulement lues. Le conteneur a besoin d'une première sauvegarde dans BombVault, pour que la restauration ait sa définition. La rétention ne touche pas aux points de restauration importés, supprimez donc vous-même celui dont vous n'avez plus besoin.

Stockage et planification

• Sauvegardes incrémentales et dédupliquées via restic, de sorte que même de grandes images disque de VM ne font pas exploser le dépôt.
• Destinations : un chemin local, ou hors site. Des partages SMB et des serveurs WebDAV (Nextcloud, ownCloud, SharePoint) directement depuis un formulaire sous Paramètres, Accès cloud, rclone, sans montage sur l'hôte ; NFS (montez l'export sur Unraid et pointez-y un Chemin de sauvegarde) ; backends restic natifs sans rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo), ou n'importe quel remote rclone via rclone:<remote>:<bucket>/path. Tous les identifiants sont stockés chiffrés.
• Les cibles SSH ne nécessitent rien d'installé côté distant. sftp: requiert seulement un serveur SSH, de sorte qu'un simple Raspberry Pi (sans Docker, sans restic) fonctionne comme destination hors site. Les clés d'hôte sont épinglées automatiquement au premier contact.
• Copie hors site (local + distant). Conservez la sauvegarde locale rapide et ajoutez un ou plusieurs réplicas hors site, répliqués avec restic copy au mieux (un accroc hors site ne fait jamais échouer la sauvegarde locale). Chaque domaine a son propre planning hors site, plus un bouton Répliquer maintenant.
• Plusieurs cibles hors site par domaine. Chaque domaine (conteneurs, VMs, flash, config, jeux de fichiers et jeux de données ZFS) peut répliquer vers plusieurs destinations hors site à la fois, pas seulement une. Ajoutez des cibles supplémentaires dans la page Hors site, chacune avec son propre dépôt, sa classe de stockage S3, son indicateur append-only, sa rétention et son budget de croissance. Votre copie hors site existante est reprise comme première cible, de sorte que rien ne change tant que vous n'en ajoutez pas une seconde, et chaque cible d'un domaine réplique selon le planning hors site de ce domaine.
• Dépôts nommés. Notez une fois pour toutes vos emplacements de sauvegarde sous Paramètres, Stockage, Dépôts, un chemin local ou n'importe quel remote restic avec son propre ensemble d'identifiants, puis choisissez-en un comme emplacement d'un élément sur sa carte. Chaque ligne indique combien d'éléments pointent vers ce dépôt, et un dépôt utilisé par un élément ou par un emplacement par défaut ne peut être ni déplacé ni supprimé, car BombVault ne déplace jamais une sauvegarde déjà écrite.
• Plusieurs ensembles d'identifiants cloud. Les identifiants cloud partagés s'appliquent partout par défaut, mais chaque destination peut choisir à la place un ensemble d'identifiants nommé (Paramètres, Accès cloud, Ensembles d'identifiants supplémentaires), si bien qu'un bucket S3 chez Hetzner et un serveur Garage local peuvent fonctionner côte à côte, chacun avec sa propre clé. Cela vaut aussi pour les cibles hors site et pour un chemin de sauvegarde qui est lui-même un dépôt distant.
• Destinations. Une destination hors site se configure une seule fois, avec un assistant qui liste les services de stockage S3, votre propre serveur S3, votre propre serveur et vos partages, et tous les stockages cloud que rclone prend en charge, avec la connexion, un test de connexion, un sélecteur de dossier et un mot honnête sur la protection contre la suppression. Elle apparaît ensuite comme un bouton sur chaque domaine et chaque élément. Voir Destinations.
• Emplacement par élément. Chaque carte de conteneur, VM et jeu de fichiers a une ligne de boutons, Local et un par cible hors site, et les boutons allumés reçoivent ses sauvegardes. Un partage déjà sur un NAS n'a plus besoin d'aller aussi vers B2. L'emplacement est fixé dès la première sauvegarde, les copies peuvent changer à tout moment, et la carte dit combien de sites détiennent l'élément et si 3-2-1 est respectée. Voir Emplacement par élément.
• Emplacements par défaut. Une ligne par domaine définit où les nouveaux éléments sont écrits et vers quelles cibles sont copiés les éléments sans choix propre. La changer ne déplace aucune sauvegarde et dit à l'avance quelles cibles gagnent ou perdent des éléments.
• Ordre de sauvegarde manuel. Définissez l'ordre exact dans lequel vos conteneurs sont sauvegardés depuis le panneau d'ordre de sauvegarde sur la page Conteneurs. Les exécutions planifiées et multi-sélection le suivent ; tout conteneur laissé sans ordre conserve le comportement précédent du plus en retard d'abord, et une sauvegarde de conteneur unique est inchangée.
• Rétention configurable : conserver-les-derniers / quotidiens / hebdomadaires / mensuels / annuels, élagués automatiquement après chaque sauvegarde, définie par source (locale comme hors site toutes deux dans Paramètres, Rétention, afin de pouvoir garder les copies hors site plus longtemps comme archive). Chaque source peut aussi suivre ses propres règles, en local et hors site (Règles de rétention par source), par exemple 7 sauvegardes quotidiennes pour des conteneurs qui changent chaque jour et moins pour des VM qui changent rarement.
• Compression par dépôt : Désactivé, Automatique (le réglage par défaut de restic) ou Maximum, réglable dans Paramètres, Stockage pour chaque chemin de sauvegarde et chaque dépôt nommé, et dans Paramètres, Hors site pour chaque destination hors site. Les sauvegardes, les copies hors site et l'élagage écrivent avec, et le kit de récupération l'indique, pour que restic seul puisse continuer à écrire de la même façon.
• Planification par domaine (quotidien / hebdomadaire incluant des jeux multi-jours / tous-les-N-jours / cron brut), le tout édité au même endroit dans Paramètres, Plannings. Un conteneur, une VM, un jeu de fichiers ou un élément ZFS peut avoir sa propre cadence, et Tous les N jours fonctionne aussi pour l'essai de restauration, le test de sabotage et le résumé hebdomadaire.
• Attendre que l'application soit au repos. Un conteneur peut faire attendre sa sauvegarde planifiée tant que son application est occupée, au plus le nombre d'heures que tu fixes, et la lancer dès que l'application est au repos. Un serveur multimédia est au repos quand il ne diffuse pas, tout autre conteneur quand son CPU et son trafic restent quelques minutes sous les limites de Paramètres, Plannings (sur le réseau de l'hôte, seul le CPU compte). La sauvegarde en attente apparaît dans le journal d'activité et sur le conteneur avec sa raison et son échéance. Elle ne tient aucun verrou, les autres conteneurs continuent donc. Les sauvegardes manuelles n'attendent jamais. Les membres d'une stack compose dus dans la même exécution attendent ensemble, et une attente reprend avec son échéance après un redémarrage. Désactiver les conteneurs abandonne toutes les sauvegardes en attente, et désactiver leur planification abandonne celles que ses exécutions ont retenues. Réduire les heures raccourcit aussi une attente déjà commencée.
• Limites de bande passante hors site. Plafonnez le débit d'envoi/de téléchargement de restic afin que la réplication ne sature pas votre WAN.
• Le streaming d'abord. Pendant qu'un serveur multimédia comme Plex, Jellyfin ou Emby diffuse, les copies hors site envoient avec une limite plus basse et reviennent à la normale quelques minutes après la fin du flux. BombVault lit dans Docker le trafic sortant des serveurs multimédias. REST, S3, B2, Azure, Google Cloud, Swift et rclone via HTTP ralentissent en pleine copie ; SFTP et les dossiers locaux ou montés prennent la limite basse à leur prochaine étape de copie. Un serveur multimédia sur le réseau de l'hôte ne peut pas être mesuré. Dans Paramètres, Hors site.
• Classe de stockage froid et archivage (S3). Pour un dépôt hors site S3 natif, vous pouvez choisir la classe de stockage, restreinte aux niveaux lisibles à la restauration (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval), afin qu'une tarification d'archivage ne casse jamais silencieusement une restauration. Les niveaux d'archivage profond qui nécessitent d'abord un dégel asynchrone (Glacier Flexible, Deep Archive) sont volontairement laissés de côté. Backends S3 natifs uniquement ; les remotes rclone définissent leur classe dans la config rclone.
• Les dossiers de sauvegarde restent copiables hors de la machine. Après chaque sauvegarde, BombVault assouplit l'arborescence du dépôt local à dossiers 0755 / fichiers 0644 (les dépôts sont chiffrés, donc rien n'est exposé), afin qu'un utilisateur de synchronisation non-root via SMB ne soit pas bloqué. Les définitions de récupération vivent à l'intérieur de chaque dépôt, de sorte qu'un dossier de dépôt copié est entièrement autonome.

Analyse, vérification et surveillance

• Pause depuis la carte. Chaque carte de conteneur, de VM et de jeu de dossiers propose Suspendre le planning, qui retire l'élément du planning et de la Sauvegarde complète, et Reprendre le planning pour le remettre. Elle agit sur le même commutateur que Inclure dans le planning, les deux concordent donc toujours. Un élément en pause porte un badge gris Planning suspendu, et Sauvegarder maintenant fonctionne toujours.
• État de protection (RPO). Le tableau de bord affiche un indicateur vert / orange / rouge par domaine, comparant la dernière sauvegarde réussie à son planning, de sorte qu'une sauvegarde en retard devient rouge au lieu de se cacher dans un journal.
• Carte de chaleur de santé des sauvegardes. Un calendrier de style contributions GitHub des résultats de sauvegarde par jour et par domaine, avec un bascule Conteneurs / VMs / Flash / Auto-sauvegarde / Dossiers.
• Chronométrage des exécutions partout. Chaque entrée d'historique d'exécution se lit début, fin (durée), et chaque conteneur et VM porte sa propre liste Exécutions récentes sur sa page.
• Un tableau de bord que vous pouvez réorganiser. Activez le mode personnalisation pour faire glisser les cartes dans votre ordre et masquer celles dont vous n'avez pas besoin. La disposition est enregistrée par navigateur.
• Taille du dépôt et tendance de déduplication. Taille actuelle du dépôt, ratio de déduplication et nombre d'instantanés par domaine, avec un sparkline de la croissance du stockage.
• Essais de vérification de restaurabilité. BombVault prouve périodiquement que vos sauvegardes sont restaurables (restic check --read-data-subset, borné) et affiche un badge Restaurabilité vérifiée par domaine.
• Contrôle de restauration après la première sauvegarde. Quand la première sauvegarde d'un élément est terminée, BombVault en restaure un échantillon (jusqu'à 100 fichiers et 256 Mio) dans un dossier temporaire sous le dossier de restauration, fait relire chaque fichier par restic contre ses empreintes et compare les tailles avec la sauvegarde. Pour un fichier trop gros pour l'échantillon, comme un disque de VM, ce sont les 64 premiers Mio qui sont relus. La carte de l'élément affiche le résultat, un échec part en notification, et Vérifier la restauration lance le même contrôle sur la sauvegarde la plus récente quand vous le souhaitez. Les sauvegardes suivantes ne le répètent pas.
• Test de démarrage. Des octets corrects ne prouvent pas que l'application redémarre. Test de démarrage sur la carte d'un conteneur restaure sa sauvegarde la plus récente dans une copie isolée et la démarre : un nom commençant par bombvault-test-, un réseau Docker interne à elle sans port publié ni accès au LAN, 1 CPU et 2 Gio de mémoire, et les données dans un dossier temporaire sous le dossier de restauration. Le test réussit quand le healthcheck du conteneur signale l'état sain, sans healthcheck quand son premier port exposé répond depuis ce réseau, et sans les deux quand il reste en marche. Le conteneur d'origine n'est jamais arrêté ni modifié, et la copie, son réseau et ses données sont supprimés ensuite, même si BombVault redémarre en plein test. Les conteneurs sur le réseau de l'hôte, privilégiés, avec des périphériques ou qui dépendent d'un autre conteneur sont affichés comme non testables. Activez Test de démarrage dans les contrôles de restauration planifiés pour tester un conteneur par exécution, en commençant par celui testé il y a le plus longtemps. Le résultat s'affiche sur la carte et sur le tableau de bord. La copie ne porte aucune étiquette de l'original et tourne sans les capabilities, options de sécurité, sysctls et cgroup parent que l'original ajoute. Un conteneur qui en a besoin échoue au test, et le résultat indique ce dont la copie a été privée.
• Opérations auto-réparatrices. Un verrou restic prouvé orphelin (laissé par un redémarrage en pleine opération) est forcé à se libérer et réessayé une fois, automatiquement. La rétention est stable en identité (élaguée par élément, immunisée contre les changements de chemin ou d'hôte) et un échec de rétention envoie une notification.
• Avertissements que l'analyse des dossiers ne voit pas. L'assistant d'exclusion répond à une question de taille. Certaines des erreurs de sauvegarde les plus coûteuses ne sont pas des questions de taille, il porte donc aussi des mises en garde propres à chaque application sur la façon dont elle stocke ses données. Celle pour laquelle il existe : Immich conserve les albums, les visages et les dates de chaque photo dans une base PostgreSQL qui tourne dans un conteneur séparé, de sorte qu'une sauvegarde au niveau fichier du conteneur Immich restaure les images sans rien de tout cela, et la restauration a l'air d'avoir fonctionné. L'avertissement s'affiche qu'une exclusion soit proposée ou non, y compris sur un conteneur où rien n'est sélectionné pour l'analyse, car la mise en garde reste vraie dans tous les cas.
• Non sauvegardé (couverture). Une carte du tableau de bord qui nomme tout ce qui, sur le serveur, n'est couvert par aucune sauvegarde automatique, avec la raison pour chaque cas : jamais ajouté à BombVault, présent mais pas inclus dans le planning, son propre planning désactivé, ou aucun planning activé nulle part. L'indicateur de protection au-dessus répond à une autre question, à savoir si les sauvegardes qui sont planifiées ont tourné à l'heure, et il ne peut pas voir le conteneur que personne n'a jamais configuré : celui-là est absent de toutes les listes et de toutes les erreurs, donc rien ne passe à l'orange pour lui. Les conteneurs sont lus dans la liste Docker en direct plutôt que dans les propres lignes de BombVault, car un élément sans ligne est justement celui qu'il faut nommer. Un type de sauvegarde que vous avez désactivé est entièrement exclu du décompte, puisque c'était votre choix.
• Aperçu de la rétention. Le panneau à côté des réglages de rétention montre ce que la prochaine exécution va supprimer, avant que cela n'arrive : par dépôt et par élément, avec les points de restauration nommés. Il ne prend aucun verrou de dépôt et ne modifie rien, il répond donc même pendant qu'une sauvegarde tourne. Une rétention désactivée l'indique au lieu d'afficher une liste vide, un dépôt append-only est signalé comme tel (la rétention n'y tourne jamais), et un dépôt injoignable est nommé au lieu de manquer en silence. Sous Paramètres, Rétention pour la politique locale comme pour la politique hors site, chacune avec son propre aperçu.
• Anomalies. Chaque sauvegarde d'un conteneur, d'une VM, d'un ensemble de dossiers, d'un dump de base de données, de la clé flash et de l'auto-sauvegarde est comparée à l'historique propre de cet élément. Les contrôles portent sur les nouvelles données d'une exécution, comparées aux plus grandes quantités habituelles des dernières sauvegardes et au débit horaire habituel ; sur une sauvegarde qui a réenregistré la plupart des données, y compris des fichiers renommés et réécrits ; sur la taille de la source et le nombre de fichiers que restic indique pour chaque élément et chaque dump ; sur la durée de sauvegarde propre à restic ; sur les séries d'échecs et les échecs intermittents ; sur les contrôles de restauration qui ne passent plus ; et sur l'espace libre des dépôts locaux, SFTP et rclone, projeté à partir de la croissance du dépôt. Un élément apprend de ses 10 premières sauvegardes, tandis qu'une source presque vide, la réécriture de la plupart des données et les échecs sont contrôlés dès le départ. Lors de la mise à jour, l'historique est lu une fois dans les résumés de snapshots que stocke restic 0.17, si bien qu'une installation existante ne part pas de zéro. La sensibilité (Stricte, Équilibrée, Permissive) et la gravité minimale qui envoie une notification se règlent globalement dans Paramètres, Intégrité et peuvent être modifiées par élément. Les avertissements se ferment d'eux-mêmes une fois la cause disparue ; les constats critiques de perte de données et de disque qui se remplit restent jusqu'à ce que vous en accusiez réception, et un constat acquitté n'est pas signalé à nouveau tant que sa cause n'a pas disparu une fois. Marquer comme attendue fait d'un nouveau niveau la norme après 10 sauvegardes, mais ne désactive jamais le contrôle de source presque vide, et une sélection modifiée fait repartir l'historique de l'élément d'elle-même. Tant qu'une source est presque vide, a fortement rétréci ou qu'une sauvegarde a réenregistré la plupart des données, la rétention garde les anciennes sauvegardes de cet élément jusqu'à ce que vous accusiez réception du constat ou le marquiez comme attendu, et le constat renvoie vers la dernière bonne sauvegarde. Une notification part une fois par épisode, et les échecs et contrôles de restauration qui notifient déjà ne sont pas signalés deux fois. Ce que la fonction ne fait pas : les dépôts S3, B2 et REST n'ont pas de valeur d'espace libre, sur le partage utilisateur d'Unraid l'espace libre est celui de toute la grappe, et les sauvegardes antérieures à restic 0.17 n'ont pas d'historique de taille. Les éléments ZFS sont vérifiés aussi, jeu de données par jeu de données : chaque jeu de données d'une arborescence a son propre historique, un jeu vidé ou devenu illisible compte comme une perte de données, et seules les anciennes sauvegardes de ce jeu sont conservées. La surveillance d'un élément ZFS jeu de données par jeu de données est décrite dans Jeux de données ZFS, et un assistant peut lire les anomalies ouvertes via le serveur MCP. Un constat sur la taille ou le nombre de fichiers d'une source est daté de la première sauvegarde où il est apparu, et Comparer avec la sauvegarde précédente liste les dossiers où des fichiers ont disparu, sont arrivés ou ont changé, avec une remarque quand presque tout se trouve dans un index de recherche, un cache ou des vignettes que l'application reconstruit d'elle-même.
• Exclusions recommandées par application. Pour les images connues (Plex, Jellyfin, Emby, Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Immich, Nextcloud, PhotoPrism et Tautulli, de linuxserver, hotio, binhex ou de l'éditeur officiel), l'Assistant d'exclusion propose les dossiers que l'application remplit d'elle-même : caches, journaux, images d'aperçu et affiches. Chaque entrée dit ce qu'elle contient, chacune peut être désactivée, et rien n'est exclu avant que vous appuyiez sur Exclure la sélection.
• Paquet d'assistance. Un ZIP expurgé, en un clic, pour un rapport de bug : la vérification d'intégration à l'hôte, votre configuration débarrassée de tous ses secrets, les exécutions récentes, ce qui est planifié ensuite et le journal récent. Il indique aussi comment s'est passé le dernier dump de chaque base de données, les éléments ZFS avec les montages que voit le conteneur, les anomalies ouvertes, et combien de clés MCP existent (jamais leurs noms). Les mots de passe, les jetons, la config rclone, les identifiants de notification et tout mot de passe intégré à un emplacement de dépôt sont retirés, et le paquet le dit dans son propre manifeste, car un fichier d'assistance ne doit jamais être pris pour une sauvegarde de configuration. Il exige un mot de passe de connexion pour la même raison que le kit de récupération. Le journal qu'il contient est la sortie de ce conteneur depuis son dernier démarrage ; pour un plantage qui a redémarré le conteneur, c'est toujours docker logs qu'il faut consulter.
• Kit de récupération de clé de chiffrement. Téléchargement en un clic de la clé maîtresse, du mot de passe restic dérivé et des emplacements et commandes exacts du dépôt, afin que vous puissiez restaurer sans un BombVault en fonctionnement. Voir Sauvegarde hors site et récupération.
• Exporter et importer vos réglages. Une carte Exporter / importer les paramètres sur la page Paramètres, Système écrit toute votre configuration (réglages de domaine, cibles hors site, plannings, rétention, notifications) dans un fichier JSON portable, de sorte que migrer vers une nouvelle machine ou cloner une configuration ne signifie pas tout ressaisir à la main. Vous choisissez d'inclure ou non les identifiants hors site et de notification ; avec eux, le fichier est aussi sensible que votre kit de récupération. L'import affiche un aperçu et demande confirmation, et ne touche jamais à vos données ou votre historique de sauvegarde.
• Notifications. Webhook (Discord / Slack / Gotify / ntfy), Matrix, Healthchecks.io, e-mail (SMTP), un serveur Apprise API auto-hébergé, et le système de notifications natif d'Unraid. Politique par sauvegarde : jamais / en cas d'échec / toujours. Une exécution planifiée de nombreux éléments peut envoyer un unique résumé N sur M réussis. Healthchecks reçoit tout le cycle de vie (/start, puis succès ou /fail) dès qu'une URL est définie.
• Résumé hebdomadaire. Un message par semaine, par les mêmes canaux : le nombre d'exécutions, la quantité de nouvelles données de sauvegarde, si le hors site est à jour et les principaux échecs. Désactivé par défaut, avec sa propre cadence dans Paramètres, Notifications, si bien qu'une semaine calme est signalée elle aussi.
• /metrics Prometheus. Optionnel (désactivé par défaut, jeton bearer facultatif) pour Grafana ou Uptime Kuma. Expose l'état, les tailles et les horodatages des sauvegardes, sans secrets ni chemins dans les labels.
• API HTTP, Home Assistant et mDNS. Les scripts et les tableaux de bord disposent d'une API sous /api/v1 avec des jetons nommés, en lecture seule ou autorisés à lancer des sauvegardes. Home Assistant trouve BombVault par la découverte MQTT, sous la forme d'un appareil avec des capteurs et, si vous l'autorisez, un bouton de sauvegarde par domaine. Enfin, BombVault s'annonce sur le réseau sous le nom bombvault.local. Voir API et intégrations.
• Espace libre et semaines avant saturation. Les dépôts locaux, les dépôts SFTP et les destinations SMB ou WebDAV qui le communiquent affichent leur espace libre et le nombre de semaines restantes au rythme de croissance actuel. Les dépôts S3, B2 et REST affichent « Espace libre inconnu », car ces backends ne le communiquent pas.
• Taille par dossier. Dans la section Sauvegardes d'un conteneur, d'une VM ou d'un ensemble de dossiers, Taille par dossier montre quels dossiers et fichiers occupent de la place dans la sauvegarde la plus récente et combien la dernière sauvegarde en a apporté de nouveau ou de modifié, un niveau à la fois. BombVault le lit dans l'index du dépôt sans lire les fichiers et, dès que vous l'avez ouvert une fois, le tient à jour après chaque sauvegarde.
• Pourquoi une sauvegarde a été lente. Pendant une sauvegarde, BombVault regarde à quel point le processeur, les disques et le réseau sont occupés. Quand une sauvegarde dure bien plus longtemps que d'habitude et qu'une seule chose était nettement à sa limite, l'exécution l'indique, par exemple « Le disque cible disk1 était occupé à 98 % » ou « BombVault a utilisé 100 % de la limite de processeur de son conteneur ». Sinon, elle n'indique rien.
• Modifié depuis la dernière sauvegarde. Un conteneur recréé avec une autre image, d'autres ports, variables ou volumes depuis sa dernière sauvegarde reçoit une marque à côté de son nom. Son (i) liste ce qui a changé, les variables par leur nom seulement. Ce n'est qu'une note, qui disparaît avec la sauvegarde suivante.

Protection contre les rançongiciels

• Hors site immuable (append-only). Marquez un dépôt hors site en append-only afin qu'un rançongiciel ou un hôte compromis ne puisse ni supprimer ni réécrire vos sauvegardes. Le côté distant (un restic/rest-server en mode --append-only) l'impose ; BombVault ne fait que le vérifier et n'affiche jamais du vert sur la seule foi d'une déclaration de configuration.
• Test de sabotage. BombVault prouve périodiquement la garantie append-only en tentant réellement une suppression contre le dépôt hors site (visant un objet inexistant) : refusé signifie protégé, accepté signifie non protégé. Un résultat non concluant ne renverse jamais le verdict stocké.
• Configuration hors site guidée. Un assistant vous accompagne du choix du backend jusqu'à un extrait de déploiement rest-server prêt à coller, un test de connexion, la bascule d'immuabilité et une stratégie de rétention.
• Essais de reprise après sinistre (hors site). Restaurez une vraie cible depuis le dépôt hors site dans un bac à sable jetable, vérifiez-la fichier par fichier et octet par octet, puis nettoyez. Voir Sauvegarde hors site et récupération.
• Tableau de bord de protection contre les rançongiciels. Une carte du tableau de bord avec une posture verte / orange / rouge par domaine et une liste de contrôle horodatée ; chaque ligne rouge renvoie directement au correctif. Elle ne passe au vert que sur des faits vérifiés.
• Alarme de budget de croissance. Pour un hors site immuable (où les anciens instantanés ne sont délibérément jamais élagués), définissez un budget de taille et soyez alerté avant qu'il ne s'emballe.
• Appairage par phrase. Les instances rejoignent un même groupe avec douze mots : créez la phrase sur l'une, saisissez-la sur la suivante. Les membres sur le même réseau se parlent directement, les autres passent par un relais (le relais du projet, le vôtre, ou aucun), et chaque appel entre eux est chiffré de bout en bout. Le groupe transporte les fiches de protection de la page Instances, les offres de stockage hors site du Mesh et ce dont un Récepteur ou une source de Rapatriement a besoin, jamais les données de sauvegarde et jamais l'APP_KEY. Voir Sauvegarde hors site et récupération.
• Page Instances. Activez Instances dans les Paramètres pour obtenir une page avec une carte pour chaque instance de votre groupe, celle-ci comprise : son adresse, si elle est connectée, et l'état de protection de chaque domaine avec sa dernière sauvegarde, dans le même rouge, orange et vert que le tableau de bord local. Vérifier maintenant demande à un membre de vérifier le dépôt d'un domaine. Rien sur cette page ne peut lancer une sauvegarde, restaurer ou supprimer quoi que ce soit sur une autre machine.
• Mesh hors site. Un membre peut proposer son propre stockage hors site à un autre membre via le groupe. L'administrateur de l'autre instance voit l'offre sur la page Instances et l'accepte ou la refuse ; l'accepter crée un ensemble d'identifiants et une cible hors site ordinaires. Seules les informations de connexion transitent ainsi, jamais les données de sauvegarde.
• Tableau de bord récepteur (côté réception). Sur la machine qui reçoit des copies hors site immuables d'un autre BombVault, activez la bascule Récepteur (Paramètres) pour révéler un onglet Récepteur. Enregistrez un dépôt reçu en lecture seule (ouvert avec le mot de passe restic de l'instance émettrice, qui arrive par le groupe d'appairage) pour voir son inventaire d'instantanés groupé par source, quand chaque source est arrivée pour la dernière fois, et lancer un restic check indépendant sur le matériel de réception. Il vous alerte lorsqu'une source cesse d'émettre dans une fenêtre que vous définissez (un dispositif d'homme mort) ou lorsqu'une vérification d'intégrité échoue. Strictement en lecture seule, il n'écrit donc jamais dans le dépôt reçu, et est désactivé par défaut. Voir Sauvegarde hors site et récupération.
• Rapatriement depuis une autre instance (côté récupération). L'image miroir de la réplication hors site : au lieu que cette machine pousse ses instantanés vers l'extérieur, elle récupère ceux d'une autre. Activez la bascule Rapatriement (Paramètres) pour révéler l'onglet Rapatriement de la page Instances, choisissez l'autre instance dans votre groupe d'appairage ainsi que l'emplacement de son dépôt, puis choisissez quel type de sauvegarde il contient et à quelle fréquence le récupérer. Son mot de passe restic arrive par le groupe, jamais son APP_KEY. Le côté distant n'a plus rien à configurer et n'a pas besoin de tourner. Le dépôt source n'est jamais que lu : il est ouvert pour vérifier le mot de passe, listé, et nommé comme source de la copie, et jamais initialisé, déverrouillé, élagué ou écrit. Chaque côté garde ses propres identifiants, et une source rclone: est refusée car rclone l'atteindrait avec les remotes de cette instance. Voir Sauvegarde hors site et récupération.

Exports en clair

• Export en clair de conteneur. Un bouton Exporter (tar brut) par conteneur écrit une copie parcourable et sans outil à côté du dépôt : <name>.tar.gz des dossiers de sauvegarde plus le modèle Unraid <name>.xml. Restic reste le moteur ; c'est une copie de confort supplémentaire.
• Export en clair de VM. Les VMs ont le même Exporter (tar brut) : <name>.tar.gz de la ou des images disque plus <name>.xml, restaurable avec virsh define plus le disque, sans BombVault ni restic.
• Chiffrer les exports en clair (age). Les exports se trouvent en dehors de restic, ils sont donc en clair par défaut. Activez le chiffrement age dans les Paramètres et ajoutez un ou plusieurs destinataires (une clé publique age ou une clé publique SSH). Chaque export (.tar.gz de conteneur et de VM, leurs fichiers annexes .xml, et le ZIP flash) est alors scellé pour ces destinataires, et vous le déchiffrez plus tard hors de la machine avec la clé privée correspondante. Par règle de sécurité, avec le chiffrement activé et aucun destinataire valide, un export échoue avec une erreur claire au lieu d'écrire du texte en clair.
• Le kit de récupération est scellé aussi. Avec le même réglage activé, le kit se télécharge sous bombvault-recovery-kit.md.age. Il est en armure ASCII plutôt que binaire, il reste donc du texte lisible : vous pouvez toujours le coller dans un gestionnaire de mots de passe ou l'imprimer, et c'est à cela que sert le kit. La même règle de sécurité s'applique : avec le chiffrement activé et aucun destinataire utilisable, le téléchargement est refusé au lieu de livrer la clé maîtresse en clair. Un point à ne pas manquer quand vous activez ceci : il vous faut votre clé privée age pour ouvrir le kit, gardez donc cette clé à un endroit qui ne dépend pas du kit lui-même.

Assistants IA (MCP)

BombVault intègre un serveur MCP, grâce auquel un assistant comme Claude Code ou Claude Desktop peut lire l'état des sauvegardes, la couverture, l'historique des exécutions, les points de restauration et l'activité en cours. Avec une clé qui l'autorise, l'assistant peut aussi lancer la sauvegarde d'un élément, d'un domaine ou de tout, et annuler les sauvegardes qu'il a lancées. Les restaurations, les suppressions, prune et les paramètres restent dans l'interface web. Chaque client reçoit sa propre clé sous Paramètres, Intégrations, Serveur MCP ; une clé s'affiche une seule fois, n'est stockée que sous forme d'empreinte et peut être renommée, remplacée ou révoquée à tout moment. Les lancements sont limités par heure et par élément, et une garde de rétention empêche les sauvegardes d'un assistant de faire sortir vos propres points de restauration d'une politique « garder les N derniers ». Chaque exécution lancée par un assistant est marquée « via MCP » avec le nom de la clé. Voir Serveur MCP. Les sauvegardes de bases de données et les jeux de données ZFS font partie des éléments et points de restauration qu'il lit, et il peut lister les anomalies que BombVault a relevées.

Applications et compagnons

• Application Android. Tous les serveurs de votre groupe sur votre téléphone, avec le journal d'activité de chacun d'eux sur un seul écran. Elle rejoint votre groupe par code QR et ouvre chaque serveur avec la session déjà ouverte. Voir Application Android.
• Serveur récepteur. La machine qui reçoit les copies hors site peut démarrer en un clic un rest-server en mode append-only et l'offrir aux autres instances de votre groupe, chacune avec son propre identifiant. Voir Serveur récepteur.
• Paramètres, Applications. Une page qui commence par l'application Android, son APK pour la version que le serveur exécute et un code QR pour elle, suivie d'une carte pour chaque compagnon. La carte de ParleyPort propose son modèle Unraid, copie la commande Docker qui le démarre, et mène à son dépôt ainsi qu'aux réglages du relais sous Appairage. La carte du BombVault Widget propose son modèle et son dépôt, et installe ou supprime le plugin via la connexion SSH à l'hôte.
• BombVault Widget. Une tuile sur le tableau de bord d'Unraid avec le journal d'activité de BombVault et la prochaine exécution planifiée. Sans connexion SSH à l'hôte, la carte vous donne l'adresse .plg à installer sous Plugins, Install Plugin, et le plugin peut y être supprimé comme n'importe quel autre.
• Journal d'activité intégrable. Générez un jeton en lecture seule sous Paramètres, Intégrations et vous obtenez une adresse pour tout tableau de bord capable d'afficher une iframe, comme Homepage, Organizr ou Heimdall : une petite page avec seulement le journal d'activité en direct. Le jeton donne accès à ce journal et à rien d'autre, et Désactiver le révoque immédiatement. La page intégrée n'existe qu'en anglais.

Autres

• Arrêter une sauvegarde en cours. Chaque carte qui peut lancer une sauvegarde affiche un bouton Annuler la sauvegarde à côté de sa barre de progression pendant l'exécution. L'exécution est enregistrée comme annulée, pas comme échouée. L'arrêt est sans risque, car restic écrit son instantané en dernier : une exécution interrompue laisse des données non référencées et aucun instantané.
• Sauvegarder plusieurs à la fois. Multi-sélectionnez des conteneurs et cliquez sur Sauvegarder la sélection. Le lot s'exécute côté serveur, il continue donc même si vous fermez l'onglet ou perdez la connexion. BombVault ne sauvegarde jamais (et donc n'arrête jamais) son propre conteneur.
• Navigateur d'instantanés avec une liste de points de restauration, une suppression par instantané, et une arborescence de dossiers repliable pour la restauration au niveau fichier.
• Maintenance du dépôt par domaine : Vérifier (restic check), Déverrouiller (libérer un verrou bloqué), et Élaguer (applique la politique de rétention à la demande lorsqu'une est définie, sinon une simple récupération d'espace).
• Progression de la vérification, des contrôles de restauration et du nettoyage. Pendant qu'une de ces opérations tourne, le journal d'activité et la carte Intégrité montrent jusqu'où restic a compté, par exemple 12 sur 47 packs, avec le temps restant pour cette étape dès qu'il y a assez de données pour l'estimer. restic compte ici des packs, des instantanés et des fichiers d'index, pas des octets, et la barre montre donc cela ; avant le premier décompte, elle avance sans chiffre.
• Sauvegardes de bases de données automatiques. Les conteneurs PostgreSQL, MySQL et MariaDB reconnus (les images officielles, PostGIS, TimescaleDB, pgvector, pgautoupgrade, les images de base de données d'Immich, linuxserver, yobasystems et jc21 MariaDB, ainsi que mysql-server d'Oracle) sont vidangés avant chaque sauvegarde, depuis le serveur en marche. Les conteneurs qui ressemblent seulement à une base de données reçoivent la même option sur leur carte, désactivée tant que vous ne la choisissez pas. Le dump part directement dans le dépôt et y devient un point de restauration à part entière, à côté de la sauvegarde des fichiers ; il n'est jamais écrit sur un disque. Les identifiants proviennent des variables du conteneur lui-même, y compris les secrets *_FILE, et n'en sortent jamais. Chaque carte indique si le dossier de données de la base est sauvegardé à l'arrêt, copié en marche, ou pas sauvegardé du tout. Un dump en échec ne fait pas échouer la sauvegarde : il apparaît comme une exécution en échec avec sa raison et une piste pour la corriger, et déclenche une notification. Un dump n'est jamais rechargé tout seul. Téléchargez-le (brut ou compressé), enregistrez-le dans un dossier, importez-le en un clic dans une base fraîchement démarrée, ou récupérez-le avec la CLI restic. Désactivez-le par conteneur, avec le label bombvault.dbdump=false, ou pour tous les conteneurs dans les Paramètres. La détection d'anomalies surveille aussi la taille de chaque sauvegarde de base de données, et un assistant peut lister celles d'un conteneur via le serveur MCP.
• Hooks pré/post-sauvegarde par conteneur. Des commandes shell s'exécutent à l'intérieur du conteneur (par exemple vider un cache sur disque) ; un pré-hook en échec annule la sauvegarde. Les bases de données reconnues sont vidangées automatiquement et n'ont besoin d'aucun hook.
• Arrêter d'autres conteneurs pendant la sauvegarde, avec un redémarrage conditionné à la santé. Nommez les conteneurs dépendants (par exemple une base de données) à arrêter pendant la sauvegarde de celui-ci. Ensuite, BombVault les ramène dans leur ordre depends_on de Compose et, par défaut, attend que chacun se signale sain (ou en cours d'exécution, s'il n'a pas de healthcheck) avant de démarrer les conteneurs qui en dépendent, de sorte qu'une dépendance comme Pi-hole, une base de données ou une passerelle VPN soit réellement active avant les services qui en ont besoin, au lieu que ceux-ci reviennent sur un connection refused. L'attente est bornée par un délai par conteneur (120 secondes par défaut) afin qu'un conteneur lent ou jamais sain ne puisse jamais bloquer l'exécution ; l'attente comme le délai vivent dans Paramètres, Conteneurs (désactivez l'attente pour le redémarrage simultané précédent). Le même redémarrage ordonné et conditionné à la santé enveloppe aussi la mise à jour d'image post-sauvegarde, de sorte que le jour où une mise à jour arrive, les dépendants sont maintenus arrêtés pendant la recréation et ne sont ramenés, conditionnés à la santé, qu'une fois celle-ci terminée.
• Motifs d'exclusion par conteneur. Listez les sous-répertoires à ignorer à l'intérieur d'un volume sauvegardé, un par ligne. Saisissez les chemins tels que vous les voyez à l'intérieur du conteneur ; un aperçu en direct montre ce que chaque ligne résout et avertit lorsqu'une ligne n'exclurait rien.
• Mettre à jour après une sauvegarde réussie (avancé, désactivé par défaut). Activez ceci sur un conteneur et BombVault tire l'image la plus récente et le recrée, mais seulement lorsqu'il existe réellement une image plus récente, afin qu'un point de restauration frais existe toujours d'abord. Extras optionnels : une notification par conteneur mis à jour et le nettoyage d'image (une image de base partagée par d'autres conteneurs n'est jamais supprimée). Après la mise à jour, BombVault demande aussi à Unraid de revérifier l'état de mise à jour de ce conteneur, de sorte que la bannière update available périmée de l'onglet Docker se dissipe d'elle-même au lieu de s'attarder (les mises à jour Unraid passent directement par l'API Docker, donc son état en cache, et sur certaines versions un digest en cache, continueraient sinon d'afficher la bannière). C'est au mieux, n'affecte jamais la sauvegarde, activé par défaut et dispose d'une bascule dans les Paramètres.
• Restaurer vers un dossier alternatif pour le clonage ou l'inspection.
• Diff et étiquettes d'instantanés. Comparez deux instantanés pour voir ce qui a changé, et étiquetez les instantanés pour les filtrer.
• Quoi de neuf après une mise à jour. Les notes de version s'affichent une fois par nouvelle version, servies depuis des notes intégrées au binaire, de sorte que le dialogue fonctionne hors ligne.
• HTTPS par défaut (auto-signé, ou apportez votre propre certificat derrière un reverse proxy).
• Healthcheck Docker. Le conteneur se signale sain/non sain depuis son propre /api/health, de sorte qu'un outil d'auto-réparation peut le redémarrer si le moteur venait à se coincer.
• Interface sombre/claire en 42 langues avec un sélecteur de drapeaux.
• Les paramètres s'enregistrent d'eux-mêmes. Basculez un interrupteur ou quittez un champ, et la modification est écrite aussitôt, avec un bref éclair sur le contrôle et une secousse si le serveur la refuse. Trois endroits gardent un bouton Enregistrer, parce qu'un enregistrement à moitié fait y serait risqué : la zone de configuration rclone, l'éditeur d'ensembles d'identifiants et le mot de passe de connexion.
• Messages contextuels discrets. Sous Paramètres, Général, vous pouvez masquer les confirmations de routine, pour que seuls les échecs vous interrompent encore. Ce réglage vaut par navigateur et ne touche pas aux notifications envoyées par BombVault.
• À votre goût. Paramètres, Apparence règle les couleurs (une seule couleur d'accentuation, ou le Mode arc-en-ciel avec une palette de huit), les angles (arrondis, légers ou droits) et l'animation (désactivé, léger, sauvage ou déchaîné), mémorisés par navigateur. Quand votre système demande moins de mouvement, c'est lui qui l'emporte toujours.