Configuratie

Deze pagina behandelt de omgevingsvariabelen van de container, de mounts die de template levert, VM-back-up via SSH en de off-site setup. Back-uprepository-paden worden binnen de app geconfigureerd (Instellingen, Opslag, Back-uppaden), niet via omgevingsvariabelen.

Omgevingsvariabelen

Variabele	Vereist	Beschrijving
APP_KEY	Ja	32-byte hex-geheim (64 hex-tekens) gebruikt om het restic-repo-wachtwoord af te leiden. Genereer met openssl rand -hex 32. Bewaar dit veilig: kwijtraken maakt versleutelde back-ups onherstelbaar.
LIBVIRT_HOST	Voor VM's	Unraid-host bereikt via SSH voor VM-back-up (standaard host.docker.internal; de template vult vooraf een LAN-IP-placeholder in). Gebruik je Unraid LAN-IP, vereist op een custom br0.x-netwerk. Ook gebruikt voor back-ups van ZFS-datasets (templateveld Host SSH: Address); de plaatshouder 192.168.x.x geldt als niet ingesteld.
LIBVIRT_SSH_PORT	Nee	SSH-poort van de host voor VM-back-up (standaard 22). Templateveld Host SSH: Port, ook voor ZFS-datasets.
LIBVIRT_SSH_USER	Nee	SSH-gebruiker op de host voor VM-back-up (standaard root). Templateveld Host SSH: User, ook voor ZFS-datasets.
LIBVIRT_URI	Nee	Volledige libvirt-verbindings-URI, letterlijk gebruikt in plaats van er één op te bouwen uit de drie LIBVIRT_*-variabelen hierboven (die dan voor de verbindingsstring worden genegeerd). Standaard niet ingesteld. Nodig op TrueNAS Scale, waar libvirtd luistert op een niet-standaard socket die de opgebouwde vorm niet kan uitdrukken: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Zie de TrueNAS Scale-sectie van docs/vm-backup-ssh-setup.md. Is het een qemu+ssh://-URI, dan wordt elk van LIBVIRT_HOST, LIBVIRT_SSH_USER en LIBVIRT_SSH_PORT die niet is ingesteld eruit overgenomen, ook voor BombVaults eigen SSH-opdrachten (NVRAM-overdracht, ZFS-datasets).
PORT	Nee	HTTP-poort (standaard 3000; alleen gebruikt met HTTP_ONLY=true).
HTTPS_PORT	Nee	HTTPS-poort (standaard 3443; de template publiceert hem 1:1, dus de WebUI antwoordt op https://<ip>:3443).
HTTP_ONLY	Nee	Zet true om de zelfondertekende HTTPS-listener uit te schakelen en alleen platte HTTP te serveren (voor gebruik achter een TLS-terminerende reverse proxy).
BIND_HOST	Nee	Adres waarop de WebUI luistert (standaard 0.0.0.0, alle interfaces). Laat het leeg in de container, waarvan de gepubliceerde poorten alle interfaces nodig hebben; 127.0.0.1 past bij een run buiten Docker. De healthcheck vraagt hetzelfde adres.
TRUSTED_PROXY	Nee	Door komma's gescheiden adressen of CIDR-bereiken van de reverse proxy voor BombVault (bijvoorbeeld 192.168.20.11 of 10.0.0.0/8). Alleen van die hops wordt X-Forwarded-For geloofd, en de inlogrem telt mislukte pogingen dan per echte client in plaats van iedereen achter de proxy op één hoop te gooien. Niet ingesteld (de standaard) betekent niemand vertrouwen: een onvoorwaardelijk geloofde header zou elke beller zijn eigen teller laten kiezen.
HOST_SOURCE_ROOT	Nee	Het hostpad dat als Host Data wordt gemount (standaard /mnt). BombVault vertaalt de bind-mount-bronnen die Docker meldt naar paden onder deze mount. Wijzig alleen als je een andere host-root hebt gemount.
DATA_ROOT_SEGMENTS	Nee	Kommagescheiden padsegmentnamen die een bind-mount-bron als back-updata markeren (standaard appdata, overeenkomstig Unraids conventie /mnt/user/appdata/<container>). De bind-mount van een container wordt automatisch geselecteerd voor back-up zodra ELK opgegeven segment als volledig padsegment in de hostbron voorkomt; DATA_ROOT_SEGMENTS=appdata,config pikt bijvoorbeeld ook een .../config-bind op. Zie Detectie van back-upbronnen voor de andere, altijd-actieve manieren waarop de datamap van een container wordt gevonden.
PLATFORM	Nee	Forceert welk platform BombVault denkt te draaien, in plaats van automatisch te detecteren: unraid, generic of truenas (standaard niet ingesteld: detecteert Unraid automatisch door te zoeken naar diens dockerMan-marker onder de flash-mount, anders generic; een onherkende waarde valt ook terug op generic, gelogd). Stel het expliciet in op een generieke Docker-host of TrueNAS Scale, in plaats van te vertrouwen op de automatische Unraid-detectie; het generieke compose-bestand doet dit. Verandert de appdata-fallbackconventie, de standaardbestemmingen voor herstel tussen instanties, en of de Unraid-only meldings-/companion-plugin-stappen wel worden geprobeerd (zie internal/platform).
BOMBVAULT_SELF_CONTAINER	Nee	De naam van de BombVault-container zelf, zodat het nooit een back-up maakt van (en dus stopt) zichzelf.
BACKUP_MAX_HOURS	Nee	Maximaal aantal klok-uren dat een enkele back-uprun zijn domeinlock mag vasthouden voordat hij geforceerd wordt geannuleerd (een beveiliging zodat een vastgelopen run het domein niet eeuwig kan blokkeren). Leeg (de standaard) gebruikt 48. Verhoog het voor zeer grote of trage cloud-back-ups (een run die bij de limiet wordt geannuleerd mislukt met context deadline exceeded). Zet 0 om de limiet helemaal uit te schakelen.
BACKUP_STALL_HOURS	Nee	Aantal uren dat een back-up helemaal geen voortgang mag maken voordat hij wordt geannuleerd. Leeg (de standaard) gebruikt 2; zet 0 om nooit bij stilstand te annuleren. Dit is de fijnere van de twee beveiligingen en meestal degene die ingrijpt: hij kijkt of er nog iets gebeurt, niet hoe lang de run al duurt, dus een trage maar gezonde back-up van meerdere terabytes blijft met rust gelaten, terwijl een run die vastzit op een share die niet reageert na uren wordt gestopt in plaats van na dagen. Na 30 minuten stilte wordt een waarschuwing gelogd, voordat er iets wordt geannuleerd. Scannen telt als voortgang: restic schrijft geen bytes terwijl het een grote boom doorloopt, en die fase wordt bewaakt via de totalen aan bestanden en bytes in plaats van via de geschreven bytes. De twee variabelen zijn onafhankelijk, en BACKUP_MAX_HOURS begrenst nog steeds de fasen na de back-up zelf (retentie, statistieken, off-site kopie), waar geen tellers zijn om te bewaken.
DB_DUMP_MAX_HOURS	Nee	Uren die één automatische databasedump mag draaien voordat hij wordt gestopt. Leeg (de standaard) gebruikt 6; toegestaan zijn 1 tot 48, en de limiet blijft een uur onder BACKUP_MAX_HOURS (op de helft ervan als die onder twee uur ligt), zodat een lange dump door zijn eigen limiet wordt afgekapt en als zodanig wordt gemeld in plaats van de back-up mee te sleuren. Een dump die niet meer vordert, wordt eerder gestopt, na BACKUP_STALL_HOURS. Een gestopte dump mislukt op zichzelf en de back-up van de container gaat door. Voeg de variabele op Unraid toe aan de BombVault-container met Add another Path, Port, Variable.
TZ	Nee	Tijdzone voor de planner (bijvoorbeeld Europe/Berlin). Niet ingesteld betekent dat alle planningen in UTC draaien: een planning op 02:30 start dan om 02:30 UTC en niet op de lokale klok. Op Unraid stel je dit nooit zelf in: het systeem geeft zijn eigen tijdzone door aan elke container. Het opstartlogboek vermeldt welke zone daarbij is bepaald. Een zone met zomertijd slaat in het voorjaar één run over en voert er in het najaar één twee keer uit; UTC doet geen van beide, maar verschuift twee keer per jaar een uur ten opzichte van je klok.

Mounts

Mount de Docker-socket, de flash (/boot) en de root Host Data (/mnt) zoals getoond in de CA-template. Back-upbronnen en bestemmingen leven allebei onder Host Data, en het wordt slave gemount zodat een remote share die na de start van de container mount (bijvoorbeeld onder /mnt/remotes) zichtbaar wordt zonder herstart.

Back-ups van ZFS-datasets hebben deze modus ook nodig: de host koppelt de snapshot van een dataset pas aan nadat de container is gestart. Zie ZFS-datasets.

Back-uprepository-paden gaan standaard naar /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, aangemaakt bij de eerste back-up. Wijzig de locatie op elk moment in Instellingen, Opslag, Back-uppaden. Elk padveld heeft ook een schakelaar Lokaal / Extern ernaast: een pad kan een restic-remote zijn (s3:..., rest:..., sftp:..., rclone:...) in plaats van een lokale map, en dan wordt er rechtstreeks naartoe geback-upt zonder aparte lokale kopie; zie Externe primaire repositories.

Host-integratiecontrole

Open /spike in de web-UI nadat de container is gestart. Het test elke mount en CLI (Docker-socket, libvirt, restic, qemu-img, rclone) en meldt eventuele ontbrekende onderdelen.

Herkenning van de back-upbronnen

Voor elke container kiest BombVault zelf welke bind mounts en benoemde volumes worden meegenomen. Een pad wordt opgepikt zodra een van de volgende punten geldt (het resultaat kun je per container altijd overschrijven bij zijn Back-upmappen):

• Treffer op een datawortel-segment: de hostbron van de bind bevat een van de segmenten uit DATA_ROOT_SEGMENTS als volledige padcomponent (standaard alleen appdata).
• Benoemde Docker-volumes worden altijd meegenomen, want er is geen wegwerpbaar equivalent en dus niets te filteren, maar alleen wanneer het echte opslagpad van het volume op de host zelf bereikbaar is via de Host Data-koppeling, net als elk ander hostpad dat BombVault back-upt. Het standaard stuurprogramma voor lokale volumes legt een volume onder de datawortel van de daemon zelf, dus /var/lib/docker/volumes/<naam>/_data tenzij dat is aangepast (controleer met docker info -f '{{.DockerRootDir}}'). Die plek valt NIET binnen de smalle Host Data-koppeling van één map die de generieke docker-compose.yml standaard gebruikt. Een onbereikbaar volume wordt stilzwijgend overgeslagen, dat is geen fout. Om benoemde volumes op een generieke host echt te back-uppen, richt je Host Data (en HOST_SOURCE_ROOT) op een gemeenschappelijke bovenliggende map die ook de datawortel van Docker omvat: zie de Host Data-opmerking in het compose-bestand voor de afweging (Unraid omzeilt dit door om dezelfde reden heel /mnt te koppelen, zijn eigen universele conventie op het hoogste niveau).
• Projectmap van Docker Compose: draagt de container het gebruikelijke label com.docker.compose.project.working_dir (automatisch gezet door docker compose up), dan komt die map er ook bij, ongeacht of een bind op een datawortel-segment paste.
• Overschrijven met het label bombvault.data: zet het label bombvault.data=true op een container om ALLE bind mounts mee te nemen, voor een indeling die geen van beide conventies hierboven vangt (bijvoorbeeld één enkele bind /srv/plex/config zonder Compose-project). Elke niet-lege waarde behalve false telt als waar; een ontbrekend label of bombvault.data=false verandert niets.
• Label bombvault.dbdump: zet bombvault.dbdump=false op een container om zijn automatische databasedump uit te zetten (0, no en off doen hetzelfde), of noem de engine (postgres, mysql, mariadb) om een container te dumpen die BombVault zelf niet herkent. Het label wint van de schakelaar op de kaart van de container, die op Unraid de gebruikelijke weg is.

Beveiligingsmodel

Root-gelijkwaardige controle over de host

Via de Docker-socket kan BombVault containers stoppen, verwijderen en opnieuw aanmaken en appdata lezen/schrijven, en voor VM-back-up logt het via SSH in op de host (qemu+ssh://, standaard root) om virsh uit te voeren. Iedereen die de web-UI kan bereiken heeft in feite root op de host.

• Optionele wachtwoordbeveiliging (Instellingen, Beveiliging): stel een wachtwoord in om inloggen te vereisen, wis het om het uit te schakelen. Standaard uit voor gebruik in een vertrouwd LAN. Het wachtwoord wordt opgeslagen met Argon2id over een met APP_KEY gepeperde waarde, dus een gekopieerde /config is zonder de sleutel waardeloos en mét sleutel traag aan te vallen. Een nieuw wachtwoord heeft minstens 12 tekens nodig; een bestaand korter wachtwoord blijft werken tot het wordt gewijzigd. Sessies zijn ondertekend (HMAC afgeleid van APP_KEY) en een wachtwoordwijziging maakt ze ongeldig; inloggen is beperkt tot vijf mislukte pogingen per minuut per client.
• Tweefactorauthenticatie (Instellingen): een tijdcode uit een authenticator-app boven op het wachtwoord, plus acht eenmalige herstelcodes die bij het inschakelen één keer worden getoond. Het gedeelde geheim wordt versleuteld met APP_KEY bewaard, en uitschakelen vereist een actuele code.
• Passkeys (WebAuthn) krijgen een eigen kaart zodra er een wachtwoord is ingesteld. Ze werken naast het wachtwoord en vervangen het nooit, dus wie alle passkeys verwijdert, sluit niemand buiten. Ze hebben een echte domeinnaam nodig en een certificaat dat de browser vertrouwt. Het standaardadres https://<ip>:3443 is precies wat WebAuthn weigert, en de kaart zegt dat in plaats van een knop aan te bieden die mislukt.
• Wijzigingen vereisen JSON. Een verzoek dat iets wijzigt, moet Content-Type: application/json sturen en mag door de browser niet als cross-site gemarkeerd zijn, zodat een pagina op een andere site je browser geen instellingen op een LAN-adres kan laten wijzigen. Een script dat de API aanstuurt, stuurt die header mee; al het andere wordt geweigerd met 415.
• Omdat de poort opt-in is, zijn wanneer die niet is ingesteld de hele UI en API (inclusief de off-site setup, tamper-test-routes en de herstelkit) bereikbaar voor iedereen die de poort kan bereiken. Schakel de beveiliging in zodra off-site, onveranderlijke back-ups of versleuteling in gebruik zijn.
• Draai BombVault alleen op een vertrouwd, niet-blootgesteld netwerk. Zet het voor externe toegang achter een reverse proxy die authenticatie en TLS toevoegt. Antwoorden dragen basis-beveiligingsheaders (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Achter een reverse proxy draagt elk verzoek het adres van de proxy, dus zonder TRUSTED_PROXY telt de inlogrem alle clients bij elkaar en sluiten de mislukte pogingen van een aanvaller ook jou buiten. Noem de proxy in TRUSTED_PROXY om weer per client te tellen.
• Een reverse proxy voor BombVault moet de header Authorization of X-API-Key doorgeven aan /mcp en mag de antwoorden niet bufferen, anders kunnen assistenten geen verbinding maken. Zie MCP-server.
• Het MCP-endpoint /mcp antwoordt met 404 totdat er een sleutel bestaat of aanmelden via OAuth is ingeschakeld, en het vraagt elke client om zijn sleutel of token, ook als het inlogwachtwoord uit staat; geen enkel adres is uitgezonderd, ook localhost niet. Het heeft geen tools om te herstellen of te verwijderen, en het herstellen van een configuratieback-up trekt elke sleutel in. Zie MCP-server.
• Met HTTP_ONLY=true verliest de sessiecookie zijn Secure-vlag (dat moet, om over platte HTTP te werken), dus schakel het wachtwoord alleen achter een TLS-terminerende proxy in als vertrouwelijkheid ertoe doet.
• De VM-back-up-SSH-verbinding vertrouwt de host key bij het eerste contact (TOFU) en pint hem daarna vast. Verifieer de host key van de host out-of-band als je container-naar-host-pad niet vertrouwd is.
• Back-ups worden door restic versleuteld wanneer versleuteling is ingeschakeld (Instellingen; standaard aan), met de sleutel afgeleid van APP_KEY.

MCP-server

De MCP-server heeft geen omgevingsvariabele nodig. Je schakelt hem in door een sleutel aan te maken onder Instellingen, Integraties, MCP-server, en hij antwoordt op /mcp op dezelfde poort als de webinterface (bijvoorbeeld https://192.168.1.10:3443/mcp). Zonder actieve sleutel antwoordt dat pad met 404. Clients, certificaten en grenzen staan op MCP-server.

VM-back-up via SSH

BombVault maakt back-ups van KVM/libvirt-VM's zonder enig libvirt-pad te mounten. Het draait virsh op de host via SSH (qemu+ssh://), zodat het nooit je host-VM Manager kan beïnvloeden.

De libvirt-socket van de host in een container mounten is op Unraid kwetsbaar: die paden zijn van de VM Manager, en het omzetten van "Enable VMs" kan libvirt achterlaten in een toestand waarin het niet meer start. De SSH-sleutel geeft root op de host, hetzelfde vertrouwensniveau als de Docker-socket die BombVault al gebruikt.

Snelle setup:

1. Instellingen, Integraties, Host-SSH: kopieer de getoonde publieke sleutel.
2. Voeg hem toe aan Unraids /root/.ssh/authorized_keys (ook op de flash bewaard zodat hij herstarts overleeft).
3. Klik op Verbinding testen.

De template voegt --add-host=host.docker.internal:host-gateway toe zodat de container de host kan bereiken. Stel LIBVIRT_HOST in op je Unraid LAN-IP als die naam niet resolvt (bijvoorbeeld wanneer de container op een custom br0.x-netwerk draait). Als je de SSH-poort van Unraid hebt gewijzigd, stel LIBVIRT_SSH_PORT overeenkomstig in. Live snapshots hebben daarnaast de qemu guest agent in de VM nodig en de schijf op /mnt/cache (niet /mnt/user).

Volledige VM-setup en netwerkgids

De complete stap-voor-stap-gids (SSH inschakelen, persistente sleutelautorisatie, custom-netwerk- en VLAN-routing, methode per VM en probleemoplossing aan de hostkant) staat op docs/vm-backup-ssh-setup.md op GitHub.

Off-site setup

Stel een off-site replica in op de pagina Instellingen, Off-site. Zie Off-site en herstel voor de volledige workflow (onveranderlijk/append-only, tamper-testen en DR-oefeningen). Kort samengevat:

• Backends: SMB/CIFS en NFS (mount de share en wijs er een back-uppad naar), native restic-backends zonder rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo), of elke rclone-remote (rclone:<remote>:<bucket>/path). Backblaze B2 heeft hier geen eigen backend: je bereikt het via zijn S3-eindpunt (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), met de sleutel-ID en de toepassingssleutel als S3-inloggegevens.
• Gedeelde cloud-inloggegevens worden versleuteld opgeslagen onder Instellingen, Cloudtoegang, Gedeelde cloud-inloggegevens.
• SSH-doelen hebben niets geïnstalleerd nodig aan de andere kant. sftp: heeft alleen een SSH-server nodig. Voeg de publieke sleutel uit Instellingen, Integraties, Host-SSH (ook op /config/ssh/id_ed25519.pub) toe aan de ~/.ssh/authorized_keys van de doelgebruiker.
• Off-site kopie: BombVault repliceert nieuwe snapshots met restic copy op best-effort-basis, bovenop een (meestal lokale) primaire repo. Elk domein heeft zijn eigen off-site planning, plus een knop Nu repliceren.
• Meerdere off-site doelen per domein: elk domein kan tegelijk naar meerdere off-site bestemmingen repliceren. Voeg extra doelen toe op Instellingen, Off-site, elk met zijn eigen repository, S3-opslagklasse, append-only-vlag, retentie en groeibudget; ze repliceren allemaal op de off-site planning van dat domein. Een bestaande enkele off-site setup wordt overgenomen als het eerste doel.
• Bestemmingen: off-site bestemmingen stel je eenmalig in onder Instellingen, Off-site, Bestemmingen, met een wizard die elke ondersteunde dienst toont. Zie Bestemmingen.
• Plaatsing per item: elke kaart van een container, VM en bestandsset verlicht Lokaal en de doelen die zijn back-ups krijgen. Instellingen, Opslag, Standaardplaatsing legt dat per domein vast voor items zonder eigen keuze. Zie Plaatsing per item.
• Retentie per bron: het lokale en het off-site beleid staan beide op Instellingen, Bewaarbeleid (laat het off-site beleid geheel op nul om off-site snapshots nooit automatisch te trimmen). De kaarten Lokaal bewaarbeleid en Off-site bewaarbeleid hebben elk Bewaarregels per bron, waarmee containers, VM's, flash, mappen, ZFS of de zelfback-up eigen bewaarregels krijgen, voor hun lokale back-ups en voor hun off-site repo. Een bron zonder eigen regels volgt de gedeelde, en de retentie na elke back-up, de off-site kopie, een handmatige opschoning en de retentievoorvertoning gebruiken allemaal de regels van de bron waar ze aan werken. Aanvullende off-site bestemmingen houden de regels die voor ze zijn ingesteld bij Instellingen, Off-site.
• Bandbreedtelimieten: begrens de restic-upload/downloadsnelheid onder Instellingen, Off-site.
• Streaming eerst: kies onder Instellingen, Off-site de mediaservers (Plex, Jellyfin en Emby zijn voorgeselecteerd op imagenaam), de verzendsnelheid vanaf waar er een als streamend telt, de uploadlimiet tijdens het streamen en hoe lang na een stream de normale limiet terugkomt.
• Koude en archiefopslagklasse (S3): kies voor een native S3 off-site repo een herstel-leesbare tier (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). rclone-remotes stellen hun klasse in de rclone-config in.
• Externe primaire repo in plaats van lokaal: het back-uppad van een domein kan zelf een van de backends hierboven zijn, zonder lokale kopie en zonder replicatiestap. De schakelaar Lokaal/Extern naast het veld en de veiligheidsinstellingen voor bandbreedte, append-only en groeibudget staan bij Externe primaire repositories.

Anomalieën

Anomaliedetectie stel je in op de kaart Anomalieën onder Instellingen, Integriteit. Elk bedieningselement slaat meteen op, en de drie onder de schakelaar zijn verborgen zolang de detectie uit staat.

Instelling	Standaard	Wat het doet
Anomalieën detecteren	Aan	Vergelijkt elke back-up met de eigen geschiedenis van het item. Uitgeschakeld wordt er niets nieuws meer gecontroleerd en verdwijnt het item Anomalieën uit de zijbalk; de kaart linkt nog steeds naar eerdere bevindingen.
Gevoeligheid	Gebalanceerd	Streng meldt ook kleinere veranderingen, Soepel alleen grote.
Een melding sturen voor	Alleen kritieke bevindingen	De laagste ernst die een bericht stuurt via de kanalen die onder Meldingen zijn ingesteld. Herhaald mislukte back-ups en dumps en mislukte geplande herstelcontroles sturen al een eigen bericht en worden niet dubbel verstuurd.
Oude back-ups bewaren als een bron sterk krimpt of wordt herschreven	Aan	Zolang een item een open bevinding heeft voor een bijna lege bron, een sterke krimp of het grootste deel van de data opnieuw opgeslagen, laten retentie en opschonen de oude back-ups van dat item met rust. Bevestig de bevinding of markeer haar als verwacht om ze vrij te geven.

Elk item kan een eigen gevoeligheid en een eigen meldingsminimum hebben. Stel ze in op de pagina Anomalieën, waar een item met open bevindingen ze onder Bewaking op zijn kaart heeft en elk ander item ze opent vanuit de kaart Niets open, of in het eigen paneel van het item: het mappengedeelte van een container en de instellingen van een VM (allebei in de geavanceerde modus), de mappeneditor van een mappenset en de pagina's Flash en Zelf-back-up. Voor een ZFS-item staan ze in de editor op de pagina ZFS en gelden ze voor elke dataset van de boom.

Portable instellingen (exporteren en importeren)

De kaart Instellingen exporteren / importeren op de pagina Instellingen, Systeem schrijft je hele BombVault-configuratie (domeininstellingen, off-site doelen, planningen, retentie, meldingen) naar een portable JSON-bestand dat je op een andere instantie kunt importeren, zodat verhuizen naar een nieuwe machine of een setup klonen niet betekent dat je alles met de hand opnieuw invoert. Import toont een voorbeeld en vraagt om bevestiging, en raakt nooit je back-updata of historie aan.

De export kan inloggegevens bevatten

Je kiest of je de off-site-, meldings- en MQTT-brokerinloggegevens in het bestand meeneemt. Met inloggegevens erbij is de export net zo gevoelig als je herstelkit, dus bewaar hem ergens veilig. Zonder die bevat het bestand alleen niet-geheime instellingen.