Configuration¶

Cette page couvre les variables d'environnement du conteneur, les montages fournis par le modèle, la sauvegarde de VM via SSH et la configuration hors site. Les chemins de dépôt de sauvegarde se configurent dans l'application (Paramètres, Stockage, Chemins de sauvegarde), pas via des variables d'environnement.

Variables d'environnement¶

Variable	Requise	Description
`APP_KEY`	Oui	Secret hexadécimal de 32 octets (64 caractères hexa) utilisé pour dériver le mot de passe du dépôt restic. Générez avec `openssl rand -hex 32`. Gardez-le en lieu sûr : le perdre rend les sauvegardes chiffrées irrécupérables.
`LIBVIRT_HOST`	Pour les VMs et les jeux de données ZFS	Hôte Unraid atteint via SSH pour la sauvegarde de VM (par défaut `host.docker.internal` ; le modèle pré-remplit un placeholder d'IP LAN). Utilisez l'IP LAN de votre Unraid, requis sur un réseau `br0.x` personnalisé. Sert aussi aux sauvegardes de jeux de données ZFS (champ du modèle Host SSH: Address) ; la valeur fictive `192.168.x.x` compte comme non définie.
`LIBVIRT_SSH_PORT`	Non	Port SSH de l'hôte pour la sauvegarde de VM (par défaut `22`). Champ du modèle Host SSH: Port, aussi pour les jeux de données ZFS.
`LIBVIRT_SSH_USER`	Non	Utilisateur SSH sur l'hôte pour la sauvegarde de VM (par défaut `root`). Champ du modèle Host SSH: User, aussi pour les jeux de données ZFS.
`LIBVIRT_URI`	Non	URI de connexion libvirt complète, utilisée telle quelle au lieu d'en construire une à partir des trois variables `LIBVIRT_*` ci-dessus (qui sont alors ignorées pour la chaîne de connexion). Non définie par défaut. Nécessaire sur TrueNAS Scale, dont le libvirtd écoute sur un socket non standard que le format construit automatiquement ne peut pas exprimer : `qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock`. Voir la section TrueNAS Scale de docs/vm-backup-ssh-setup.md. Si c'est une URI `qemu+ssh://`, chacune des variables `LIBVIRT_HOST`, `LIBVIRT_SSH_USER` et `LIBVIRT_SSH_PORT` qui n'est pas définie en est tirée, y compris pour les commandes SSH de BombVault (transfert NVRAM, jeux de données ZFS).
`PORT`	Non	Port HTTP (par défaut `3000` ; utilisé uniquement avec `HTTP_ONLY=true`).
`HTTPS_PORT`	Non	Port HTTPS (par défaut `3443` ; le modèle le publie en 1:1, de sorte que l'interface web répond sur `https://<ip>:3443`).
`HTTP_ONLY`	Non	Mettez `true` pour désactiver l'écouteur HTTPS auto-signé et ne servir que du HTTP simple (pour un usage derrière un reverse proxy terminant le TLS).
`BIND_HOST`	Non	Adresse sur laquelle l'interface web écoute (par défaut `0.0.0.0`, toutes les interfaces). Ne la définissez pas dans le conteneur, dont les ports publiés ont besoin de toutes les interfaces ; `127.0.0.1` convient à une exécution hors de Docker. Le healthcheck interroge la même adresse.
`TRUSTED_PROXY`	Non	Adresses ou plages CIDR, séparées par des virgules, du reverse proxy placé devant BombVault (par exemple `192.168.20.11` ou `10.0.0.0/8`). L'en-tête `X-Forwarded-For` n'est cru que depuis ces sauts, et la limitation des connexions compte alors les échecs par client réel au lieu de regrouper tout le monde derrière le proxy dans un même compteur. Non défini (par défaut), personne n'est cru : un en-tête cru sans condition laisserait n'importe quel appelant choisir son propre compteur.
`HOST_SOURCE_ROOT`	Non	Le chemin hôte monté en tant que Host Data (par défaut `/mnt`). BombVault traduit les sources de bind-mount rapportées par Docker en chemins sous ce montage. À changer uniquement si vous avez monté une racine hôte différente.
`DATA_ROOT_SEGMENTS`	Non	Noms de segments de chemin séparés par des virgules qui marquent une source de bind-mount comme donnée de sauvegarde (par défaut `appdata`, conforme à la convention `/mnt/user/appdata/<container>` d'Unraid). Le bind-mount d'un conteneur est automatiquement sélectionné pour la sauvegarde dès que N'IMPORTE LEQUEL des segments listés apparaît comme un segment de chemin complet de sa source hôte : par exemple, `DATA_ROOT_SEGMENTS=appdata,config` récupère aussi un bind `.../config`. Voir Détection des sources de sauvegarde pour les autres méthodes, toujours actives, par lesquelles le dossier de données d'un conteneur est trouvé.
`PLATFORM`	Non	Force la plateforme sur laquelle BombVault se considère comme s'exécutant, au lieu de la détecter automatiquement : `unraid`, `generic` ou `truenas` (non définie par défaut : détecte automatiquement Unraid en sondant son marqueur `dockerMan` sous le montage flash, sinon `generic` ; une valeur non reconnue retombe elle aussi sur `generic`, journalisé). Définissez-la explicitement sur un hôte Docker générique ou sur TrueNAS Scale plutôt que de vous fier à la sonde automatique propre à Unraid : c'est ce que fait le fichier compose générique. Modifie la convention de repli appdata, les valeurs par défaut de destination de restauration entre instances, et si les étapes de notification/plugin compagnon propres à Unraid sont tentées ou non (voir `internal/platform`).
`BOMBVAULT_SELF_CONTAINER`	Non	Le nom du conteneur BombVault lui-même, afin qu'il ne se sauvegarde jamais (et donc ne s'arrête jamais) lui-même.
`BACKUP_MAX_HOURS`	Non	Nombre maximal d'heures d'horloge qu'une exécution de sauvegarde unique peut détenir le verrou de son domaine avant d'être forcée à s'annuler (une protection pour qu'une exécution coincée ne puisse pas bloquer le domaine à jamais). Vide (la valeur par défaut) utilise `48`. Augmentez-le pour de très grandes ou lentes sauvegardes cloud (une exécution annulée au plafond échoue avec `context deadline exceeded`). Mettez `0` pour désactiver complètement le plafond.
`BACKUP_STALL_HOURS`	Non	Heures pendant lesquelles une sauvegarde peut ne faire aucun progrès avant d'être annulée. Vide (par défaut) utilise `2` ; mettez `0` pour ne jamais annuler sur un blocage. C'est la plus fine des deux protections et généralement celle qui se déclenche : elle regarde si quelque chose se passe encore plutôt que depuis combien de temps l'exécution dure, de sorte qu'une sauvegarde lente mais saine de plusieurs téraoctets est laissée tranquille, tandis qu'une sauvegarde coincée sur un partage qui ne répond plus est arrêtée en quelques heures au lieu de plusieurs jours. Un avertissement est journalisé après 30 minutes de silence, avant toute annulation. L'analyse compte comme un progrès : restic n'écrit aucun octet pendant qu'il parcourt une grande arborescence, et cette phase est surveillée via ses totaux de fichiers et d'octets plutôt que via les octets écrits. Les deux variables sont indépendantes, et `BACKUP_MAX_HOURS` borne toujours les phases qui suivent la sauvegarde elle-même (rétention, statistiques, copie hors site), où il n'y a pas de compteurs à surveiller.
`DB_DUMP_MAX_HOURS`	Non	Heures pendant lesquelles un dump automatique de base de données peut tourner avant d'être arrêté. Vide (par défaut) utilise `6` ; les valeurs admises vont de `1` à `48`, et la limite reste une heure sous `BACKUP_MAX_HOURS` (à la moitié de celui-ci quand il est inférieur à deux heures), pour qu'un long dump soit coupé par sa propre limite et signalé comme tel au lieu d'emporter la sauvegarde avec lui. Un dump qui n'avance plus est arrêté plus tôt, après `BACKUP_STALL_HOURS`. Un dump arrêté échoue pour lui-même et la sauvegarde du conteneur continue. Sur Unraid, ajoutez la variable au conteneur BombVault avec Add another Path, Port, Variable.
`TZ`	Non	Fuseau horaire pour le planificateur (par exemple `Europe/Berlin`). Si elle n'est pas définie, toutes les planifications s'exécutent en UTC : une planification à 02:30 démarre alors à 02:30 UTC et non à l'heure locale. Sur Unraid, vous ne le définissez jamais vous-même : le système transmet son propre fuseau horaire à chaque conteneur. Le journal de démarrage indique le fuseau retenu. Un fuseau avec heure d'été saute une exécution au printemps et en exécute une deux fois à l'automne ; UTC n'a aucun de ces deux effets, mais se décale d'une heure par rapport à votre horloge deux fois par an.

Montages¶

Montez le socket Docker, la flash (/boot) et la racine Host Data (/mnt) comme indiqué dans le modèle CA. Les sources et les destinations de sauvegarde vivent toutes deux sous Host Data, et elle est montée en slave afin qu'un partage distant qui se monte après le démarrage du conteneur (par exemple sous /mnt/remotes) devienne visible sans redémarrage.

Les sauvegardes de jeux de données ZFS ont aussi besoin de ce mode : l'hôte ne monte l'instantané d'un jeu de données qu'après le démarrage du conteneur. Voir Jeux de données ZFS.

Les chemins de dépôt de sauvegarde ont pour valeur par défaut /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, créés à la première sauvegarde. Changez l'emplacement à tout moment dans Paramètres, Stockage, Chemins de sauvegarde. Chaque champ de chemin a aussi un commutateur Local / Distant intégré : un chemin peut être un remote restic (s3:..., rest:..., sftp:..., rclone:...) au lieu d'un dossier local, et la sauvegarde y va alors directement, sans copie locale séparée ; voir Dépôts primaires distants.

Vérification d'intégration hôte

Ouvrez /spike dans l'interface web après le démarrage du conteneur. Il sonde chaque montage et CLI (socket Docker, libvirt, restic, qemu-img, rclone) et signale toute pièce manquante.

Détection des sources de sauvegarde¶

Pour chaque conteneur, BombVault choisit lui-même les montages bind et les volumes nommés à sauvegarder. Un chemin est retenu dès que l'un des points suivants s'applique (vous pouvez toujours corriger le résultat par conteneur dans ses Dossiers à sauvegarder) :

Correspondance d'un segment de racine de données : la source hôte du bind contient l'un des segments de DATA_ROOT_SEGMENTS comme composant de chemin complet (par défaut appdata uniquement).
Les volumes Docker nommés sont toujours inclus, car ils n'ont pas d'équivalent jetable et il n'y a donc rien à filtrer, mais seulement si le chemin de stockage hôte réel du volume est lui-même accessible via le montage Host Data, exactement comme tout autre chemin hôte sauvegardé par BombVault. Le pilote de volumes locaux par défaut range un volume sous la racine de données du démon, soit /var/lib/docker/volumes/<nom>/_data sauf personnalisation (à vérifier avec docker info -f '{{.DockerRootDir}}'). Cet emplacement n'est PAS couvert par le montage Host Data étroit, à répertoire unique, que le docker-compose.yml générique utilise par défaut. Un volume inaccessible est ignoré en silence, ce n'est pas une erreur. Pour réellement sauvegarder les volumes nommés sur un hôte générique, pointez Host Data (et HOST_SOURCE_ROOT) vers un ancêtre commun qui couvre aussi la racine de données de Docker : voyez le commentaire Host Data du fichier compose pour le compromis (Unraid contourne le problème en montant tout /mnt, sa propre convention universelle de premier niveau, pour la même raison).
Répertoire de projet Docker Compose : si le conteneur porte le label standard com.docker.compose.project.working_dir (posé automatiquement par docker compose up), ce répertoire est ajouté lui aussi, qu'un bind ait correspondu ou non à un segment de racine de données.
Dérogation par le label bombvault.data : posez le label bombvault.data=true sur un conteneur pour inclure TOUS ses montages bind, pour une organisation qu'aucune des deux conventions ci-dessus ne rattrape (par exemple un unique bind /srv/plex/config sans projet Compose). Toute valeur non vide autre que false compte comme vraie ; un label absent ou bombvault.data=false ne change rien.
Label bombvault.dbdump : posez bombvault.dbdump=false sur un conteneur pour désactiver son dump automatique de base de données (0, no et off font la même chose), ou nommez le moteur (postgres, mysql, mariadb) pour vidanger un conteneur que BombVault ne reconnaît pas de lui-même. Le label l'emporte sur l'interrupteur de la carte du conteneur, qui est la voie habituelle sur Unraid.

Modèle de sécurité¶

Contrôle de l'hôte équivalent à root

Via le socket Docker, BombVault peut arrêter, supprimer et recréer des conteneurs et lire/écrire dans appdata, et pour la sauvegarde de VM il se connecte à l'hôte via SSH (qemu+ssh://, root par défaut) pour exécuter virsh. Quiconque peut atteindre son interface web dispose de fait de root sur l'hôte.

Protection par mot de passe optionnelle (Paramètres, Sécurité) : définissez un mot de passe pour exiger une connexion, effacez-le pour désactiver. Désactivée par défaut pour un usage en LAN de confiance. Le mot de passe est stocké avec Argon2id sur une valeur poivrée par APP_KEY : un /config copié ne vaut rien sans la clé, et reste lent à attaquer avec elle. Un nouveau mot de passe doit faire au moins 12 caractères ; un mot de passe plus court déjà en place continue de fonctionner jusqu'à son changement. Les sessions sont signées (HMAC dérivé d'APP_KEY) et un changement de mot de passe les invalide ; les connexions sont limitées à cinq échecs par minute et par client.
Authentification à deux facteurs (Paramètres) : un code temporel depuis une application d'authentification en plus du mot de passe, avec huit codes de secours à usage unique remis une seule fois à l'activation. Le secret partagé est stocké chiffré avec APP_KEY, et la désactivation exige un code actuel.
Clés d'accès (WebAuthn) : elles ont leur propre carte dès qu'un mot de passe est défini, en plus du mot de passe et jamais à sa place, si bien que supprimer toutes les clés d'accès ne bloque personne. Elles exigent un vrai nom de domaine et un certificat auquel le navigateur fait confiance. L'adresse par défaut https://<ip>:3443 est justement ce que WebAuthn refuse, et la carte le dit au lieu de proposer un bouton qui échouerait.
Les modifications exigent du JSON. Une requête qui modifie quelque chose doit envoyer Content-Type: application/json et ne doit pas être marquée comme intersite par le navigateur, de sorte qu'une page d'un autre site ne puisse pas faire modifier des paramètres par votre navigateur sur une adresse du LAN. Un script qui pilote l'API envoie cet en-tête ; tout le reste est refusé avec 415.
Parce que la protection est optionnelle, lorsqu'elle n'est pas définie, toute l'interface et l'API (y compris la configuration hors site, les routes de test de sabotage et le kit de récupération) sont accessibles à quiconque peut atteindre le port. Activez la protection dès que des sauvegardes hors site, immuables ou du chiffrement sont utilisés.
N'exécutez BombVault que sur un réseau de confiance et non exposé. Pour un accès distant, placez-le derrière un reverse proxy qui ajoute authentification et TLS. Les réponses portent des en-têtes de sécurité de base (CSP, nosniff, X-Frame-Options, Referrer-Policy).
Derrière un reverse proxy, chaque requête porte l'adresse du proxy : sans TRUSTED_PROXY, la limitation des connexions compte tous les clients dans un seul compteur et les échecs d'un attaquant vous bloquent aussi. Indiquez le proxy dans TRUSTED_PROXY pour retrouver un comptage par client.
Un reverse proxy placé devant BombVault doit transmettre l'en-tête Authorization ou X-API-Key à /mcp et ne doit pas mettre ses réponses en tampon, sinon les assistants ne peuvent pas se connecter. Voir Serveur MCP.
Le point de terminaison MCP /mcp répond 404 tant qu'aucune clé n'existe et que la connexion via OAuth n'est pas activée, et il demande sa clé ou son jeton à chaque client, même avec le mot de passe de connexion désactivé ; aucune adresse n'est exemptée, pas même localhost. Il n'a aucun outil de restauration ni de suppression, et restaurer une sauvegarde de la configuration révoque toutes les clés. Voir Serveur MCP.
Avec HTTP_ONLY=true, le cookie de session perd son indicateur Secure (il le doit, pour fonctionner sur du HTTP simple), n'activez donc le mot de passe derrière un proxy terminant le TLS que si la confidentialité importe.
La connexion SSH de sauvegarde de VM fait confiance à la clé d'hôte à la première connexion (TOFU) et l'épingle ensuite. Vérifiez la clé de l'hôte hors bande si votre chemin conteneur-vers-hôte n'est pas de confiance.
Les sauvegardes sont chiffrées par restic lorsque le chiffrement est activé (Paramètres ; activé par défaut), avec la clé dérivée de APP_KEY.

Serveur MCP¶

Le serveur MCP n'a besoin d'aucune variable d'environnement. Vous l'activez en créant une clé sous Paramètres, Intégrations, Serveur MCP, et il répond sur /mcp sur le même port que l'interface web (par exemple https://192.168.1.10:3443/mcp). Sans clé active, ce chemin répond 404. Les clients, les certificats et les limites sont décrits sur la page Serveur MCP.

Sauvegarde de VM via SSH¶

BombVault sauvegarde les VMs KVM/libvirt sans monter aucun chemin libvirt. Il exécute virsh sur l'hôte via SSH (qemu+ssh://), de sorte qu'il ne peut jamais affecter le VM Manager de votre hôte.

Monter le socket libvirt de l'hôte dans un conteneur est fragile sur Unraid : le VM Manager possède ces chemins, et basculer « Enable VMs » peut empêcher libvirt de démarrer. La clé SSH donne un accès root à l'hôte, le même niveau de confiance que le socket Docker qu'utilise déjà BombVault.

Configuration rapide :

Paramètres, Intégrations, SSH de l'hôte : copiez la clé publique affichée.
Ajoutez-la à l'/root/.ssh/authorized_keys d'Unraid (également persistée sur la flash afin qu'elle survive aux redémarrages).
Cliquez sur Tester la connexion.

Le modèle ajoute --add-host=host.docker.internal:host-gateway afin que le conteneur puisse atteindre l'hôte. Définissez LIBVIRT_HOST sur l'IP LAN de votre Unraid si ce nom ne se résout pas (par exemple lorsque le conteneur s'exécute sur un réseau br0.x personnalisé). Si vous avez changé le port SSH d'Unraid, réglez LIBVIRT_SSH_PORT en conséquence. Les instantanés à chaud nécessitent en plus l'agent invité qemu dans la VM et le disque sur /mnt/cache (pas /mnt/user).

Guide complet de configuration et de réseau des VMs

Le guide complet pas à pas (activation SSH, autorisation persistante de la clé, routage réseau personnalisé et VLAN, méthode par VM et dépannage côté hôte) se trouve sur docs/vm-backup-ssh-setup.md sur GitHub.

Configuration hors site¶

Configurez un réplica hors site dans la page Paramètres, Hors site. Voir Sauvegarde hors site et récupération pour le flux de travail complet (immuable/append-only, test de sabotage et essais de reprise après sinistre). En bref :

Backends : SMB/CIFS et NFS (montez le partage 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 (rclone:<remote>:<bucket>/path). Backblaze B2 n'a pas de backend natif ici : on le joint via son point de terminaison S3 (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), avec l'ID de clé et la clé d'application comme identifiants S3.
Les identifiants cloud partagés sont stockés chiffrés sous Paramètres, Accès cloud, Identifiants cloud partagés.
Les cibles SSH ne nécessitent rien d'installé côté distant. sftp: requiert seulement un serveur SSH. Ajoutez la clé publique de Paramètres, Intégrations, SSH de l'hôte (aussi disponible à /config/ssh/id_ed25519.pub) à l'~/.ssh/authorized_keys de l'utilisateur cible.
Copie hors site : BombVault réplique les nouveaux instantanés avec restic copy au mieux, en plus d'un dépôt primaire (généralement local). Chaque domaine a son propre planning hors site, plus un bouton Répliquer maintenant.
Plusieurs cibles hors site par domaine : chaque domaine peut répliquer vers plusieurs destinations hors site à la fois. Ajoutez des cibles supplémentaires dans Paramètres, 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 ; elles répliquent toutes selon le planning hors site de ce domaine. Une configuration hors site unique existante est reprise comme première cible.
Destinations : les destinations hors site se configurent une seule fois sous Paramètres, Hors site, Destinations, avec un assistant qui liste tous les services pris en charge. Voir Destinations.
Emplacement par élément : chaque conteneur, VM et jeu de fichiers allume Local et les cibles qui reçoivent ses sauvegardes. Paramètres, Stockage, Emplacements par défaut le définit par domaine pour les éléments sans choix propre. Voir Emplacement par élément.
Rétention par source : les politiques locale et hors site vivent toutes deux dans Paramètres, Rétention (laissez celle hors site entièrement à zéro pour ne jamais rogner automatiquement les instantanés hors site). Les cartes Rétention locale et Rétention hors site ont chacune Règles de rétention par source, qui donne aux conteneurs, VM, flash, dossiers, ZFS ou à l'auto-sauvegarde leurs propres règles de rétention, pour leurs sauvegardes locales et pour leur dépôt hors site. Une source sans règles propres suit les règles communes, et la rétention après chaque sauvegarde, la copie hors site, une purge manuelle et l'aperçu de rétention utilisent tous les règles de la source concernée. Les cibles hors site supplémentaires gardent les règles réglées pour elles dans Paramètres, Hors site.
Limites de bande passante : plafonnez le débit d'envoi/de téléchargement de restic sous Paramètres, Hors site.
Le streaming d'abord : dans Paramètres, Hors site, choisis les serveurs multimédias (Plex, Jellyfin et Emby sont présélectionnés d'après le nom de l'image), le débit d'envoi à partir duquel un serveur compte comme en streaming, la limite d'envoi pendant le streaming et le délai après un flux avant le retour de la limite normale.
Classe de stockage froid et archivage (S3) : pour un dépôt hors site S3 natif, choisissez un niveau lisible à la restauration (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). Les remotes rclone définissent leur classe dans la config rclone.
Primaire distant au lieu de local : le Chemin de sauvegarde d'un domaine peut lui-même être l'un des backends ci-dessus, sans copie locale ni étape de réplication ; voir Dépôts primaires distants pour le commutateur Local/Distant intégré et ses réglages de sécurité (bande passante, append-only, budget de croissance).

Anomalies¶

La détection d'anomalies se règle dans la carte Anomalies de Paramètres, Intégrité. Chaque contrôle enregistre dès que vous le modifiez, et les trois sous l'interrupteur sont masqués tant que la détection est désactivée.

Réglage	Par défaut	Effet
Détecter les anomalies	Activé	Compare chaque sauvegarde à l'historique propre de l'élément. Désactivé, plus rien de nouveau n'est contrôlé et l'entrée Anomalies quitte la barre latérale ; la carte renvoie toujours vers les constats antérieurs.
Sensibilité	Équilibrée	Stricte signale des changements plus petits, Permissive seulement les grands.
Envoyer une notification pour	Seulement les constats critiques	La gravité minimale qui envoie un message par les canaux configurés dans Notifications. Les échecs répétés de sauvegardes et de dumps et les contrôles de restauration planifiés en échec envoient déjà leur propre message et ne sont pas envoyés deux fois.
Garder les anciennes sauvegardes quand une source rétrécit fortement ou est réécrite	Activé	Tant qu'un élément a un constat ouvert pour une source presque vide, un fort rétrécissement ou la plupart de ses données réenregistrées, la rétention et le nettoyage laissent ses anciennes sauvegardes intactes. Accusez réception du constat ou marquez-le comme attendu pour les libérer.

Chaque élément peut avoir sa propre sensibilité et son propre minimum de notification. Réglez-les sur la page Anomalies, où un élément avec des constats ouverts les a sous Surveillance sur sa carte et où tout autre élément les ouvre depuis la carte Rien d'ouvert, ou dans le panneau de l'élément : la section des dossiers d'un conteneur et les réglages d'une VM (tous deux en mode avancé), l'éditeur de dossiers d'un ensemble de dossiers, et les pages Flash et Auto-sauvegarde. Pour un élément ZFS, ils se trouvent dans son éditeur sur la page ZFS et valent pour chaque jeu de données de son arborescence.

Réglages portables (exporter et importer)¶

La carte Exporter / importer les paramètres sur la page Paramètres, Système écrit toute votre configuration BombVault (réglages de domaine, cibles hors site, plannings, rétention, notifications) dans un fichier JSON portable que vous pouvez importer sur une autre instance, de sorte que migrer vers une nouvelle machine ou cloner une configuration ne signifie pas tout ressaisir à la main. L'import affiche un aperçu et demande confirmation, et ne touche jamais à vos données ou votre historique de sauvegarde.

L'export peut contenir des identifiants

Vous choisissez d'inclure ou non les identifiants hors site, de notification et du broker MQTT dans le fichier. Avec les identifiants inclus, l'export est aussi sensible que votre kit de récupération, conservez-le donc en lieu sûr. Sans eux, le fichier ne contient que des réglages non secrets.