Konfiguration

Denne side dækker containerens miljøvariabler, de monteringer skabelonen leverer, VM-sikkerhedskopiering over SSH og off-site-opsætningen. Repository-stier for sikkerhedskopier konfigureres inde i appen (Indstillinger, Lagring, Sikkerhedskopistier), ikke via miljøvariabler.

Miljøvariabler

Variabel	Påkrævet	Beskrivelse
APP_KEY	Ja	32-byte hex-hemmelighed (64 hex-tegn), der bruges til at udlede restic-repoets adgangskode. Generer med openssl rand -hex 32. Hold den sikker: mister du den, kan krypterede sikkerhedskopier ikke gendannes.
LIBVIRT_HOST	Til VM'er	Unraid-vært nået over SSH til VM-sikkerhedskopiering (default host.docker.internal; skabelonen forudfylder en LAN-IP-pladsholder). Brug din Unraid LAN-IP, påkrævet på et brugerdefineret br0.x-netværk. Bruges også til sikkerhedskopi af ZFS-datasæt (skabelonfelt Host SSH: Address); pladsholderen 192.168.x.x regnes som ikke sat.
LIBVIRT_SSH_PORT	Nej	Værts-SSH-port til VM-sikkerhedskopiering (default 22). Skabelonfelt Host SSH: Port, også til ZFS-datasæt.
LIBVIRT_SSH_USER	Nej	SSH-bruger på værten til VM-sikkerhedskopiering (default root). Skabelonfelt Host SSH: User, også til ZFS-datasæt.
LIBVIRT_URI	Nej	Fuld libvirt-forbindelses-URI, brugt ordret i stedet for at bygge en ud fra de tre LIBVIRT_*-variabler ovenfor (som så ignoreres for forbindelsesstrengen). Default usat. Nødvendig på TrueNAS Scale, hvis libvirtd lytter på en ikke-standard socket, som den byggede streng-form ikke kan udtrykke: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Se TrueNAS Scale-afsnittet i docs/vm-backup-ssh-setup.md. Er det en qemu+ssh://-URI, hentes hver af LIBVIRT_HOST, LIBVIRT_SSH_USER og LIBVIRT_SSH_PORT, der ikke er sat, fra den, også til BombVaults egne SSH-kommandoer (NVRAM-overførsel, ZFS-datasæt).
PORT	Nej	HTTP-port (default 3000; kun brugt med HTTP_ONLY=true).
HTTPS_PORT	Nej	HTTPS-port (default 3443; skabelonen publicerer den 1:1, så WebUI'en svarer på https://<ip>:3443).
HTTP_ONLY	Nej	Sæt true for at deaktivere den selvsignerede HTTPS-lytter og kun servere almindelig HTTP (til brug bag en TLS-terminerende reverse proxy).
BIND_HOST	Nej	Adressen, WebUI'en lytter på (default 0.0.0.0, alle interfaces). Lad den være usat i containeren, hvis publicerede porte kræver alle interfaces; 127.0.0.1 passer til en kørsel uden for Docker. Healthchecket spørger på samme adresse.
TRUSTED_PROXY	Nej	Kommaseparerede adresser eller CIDR-intervaller for den reverse proxy foran BombVault (for eksempel 192.168.20.11 eller 10.0.0.0/8). Kun fra disse hop tros X-Forwarded-For, og login-bremsen tæller så fejl pr. rigtig klient i stedet for at samle alle bag proxyen i én pulje. Ikke sat (standard) betyder, at ingen tros: en betingelsesløst troet header ville lade enhver kalder vælge sin egen pulje.
HOST_SOURCE_ROOT	Nej	Værtsstien monteret som Host Data (default /mnt). BombVault oversætter de bind-mount-kilder, Docker rapporterer, til stier under denne montering. Skift kun, hvis du monterede en anden værtsrod.
DATA_ROOT_SEGMENTS	Nej	Kommaseparerede sti-segmentnavne, der markerer en bind-mount-kilde som sikkerhedskopidata (default appdata, svarende til Unraids /mnt/user/appdata/<container>-konvention). En containers bind-mount auto-vælges til sikkerhedskopiering, når ETHVERT angivet segment optræder som et helt sti-segment i dens værtskilde, for eksempel vælger DATA_ROOT_SEGMENTS=appdata,config også en .../config-bind. Se Registrering af sikkerhedskopikilder for de andre, altid aktive måder, en containers datamappe findes på.
PLATFORM	Nej	Tvinger hvilken platform BombVault opfatter sig selv som kørende på, i stedet for at auto-detektere det: unraid, generic eller truenas (default usat: auto-detekterer Unraid ved at probe efter dens dockerMan-markør under flash-monteringen, ellers generic; en ukendt værdi falder også tilbage til generic, logget). Sæt den eksplicit på en generisk Docker-vært eller TrueNAS Scale i stedet for at stole på auto-proben, der kun virker på Unraid: den generiske compose-fil gør netop det. Ændrer appdata-fallback-konventionen, standardværdierne for gendannelsesdestination på tværs af instanser, og om notifikations-/ledsager-plugin-trinnene, der kun findes på Unraid, overhovedet forsøges (se internal/platform).
BOMBVAULT_SELF_CONTAINER	Nej	Navnet på selve BombVault-containeren, så den aldrig sikkerhedskopierer (og dermed stopper) sig selv.
BACKUP_MAX_HOURS	Nej	Maksimalt antal vægur-timer, en enkelt sikkerhedskopikørsel må holde sin domænelås, før den tvangsannulleres (en beskyttelse, så en fastlåst kørsel ikke kan blokere domænet for evigt). Tom (default) bruger 48. Hæv den til meget store eller langsomme cloud-sikkerhedskopier (en kørsel annulleret ved grænsen fejler med context deadline exceeded). Sæt 0 for at deaktivere grænsen helt.
BACKUP_STALL_HOURS	Nej	Timer, en sikkerhedskopi må gå helt uden fremdrift, før den annulleres. Tom (default) bruger 2; sæt 0 for aldrig at annullere ved stilstand. Det er den finere af de to beskyttelser og som regel den, der slår til: den holder øje med, om der stadig sker noget, ikke med hvor længe kørslen har varet, så en langsom men sund sikkerhedskopi på flere terabyte får lov at køre, mens en, der hænger på en share, som ikke svarer, stoppes efter timer i stedet for dage. Der logges en advarsel efter 30 minutters stilhed, før noget annulleres. Scanning tæller som fremdrift: restic skriver ingen bytes, mens det gennemløber et stort træ, og den fase overvåges via fil- og bytetotalerne frem for via de skrevne bytes. De to variabler er uafhængige, og BACKUP_MAX_HOURS begrænser stadig faserne efter selve sikkerhedskopien (opbevaring, statistik, off-site-kopi), hvor der ikke er nogen tællere at holde øje med.
DB_DUMP_MAX_HOURS	Nej	Timer et enkelt automatisk databasedump må køre, før det stoppes. Tomt (standard) bruger 6; tilladte værdier er 1 til 48, og grænsen holdes en time under BACKUP_MAX_HOURS (på halvdelen af den, når den er under to timer), så et langt dump afbrydes af sin egen grænse og rapporteres som sådan i stedet for at trække sikkerhedskopien med sig. Et dump, der ikke kommer videre, stoppes tidligere, efter BACKUP_STALL_HOURS. Et stoppet dump fejler for sig selv, og containerens sikkerhedskopi fortsætter. På Unraid tilføjer du variablen til BombVault-containeren med Add another Path, Port, Variable.
TZ	Nej	Tidszone for planlæggeren (for eksempel Europe/Berlin). Hvis den ikke sættes, kører alle planer i UTC: en plan sat til 02:30 starter da 02:30 UTC og ikke efter lokal tid. På Unraid indstiller du aldrig dette selv: systemet sender sin egen tidszone videre til hver container. Opstartsloggen viser, hvilken zone der blev fundet. En zone med sommertid springer én kørsel over om foråret og kører én to gange om efteråret, mens UTC ikke gør nogen af delene, men til gengæld forskubber sig en time i forhold til dit ur to gange om året.

Monteringer

Montér Docker-socket'en, flashen (/boot) og Host Data-roden (/mnt) som vist i CA-skabelonen. Både kilder og destinationer for sikkerhedskopier lever under Host Data, og den er monteret slave, så en remote share, der monteres, efter containeren er startet (for eksempel under /mnt/remotes), bliver synlig uden en genstart.

Sikkerhedskopi af ZFS-datasæt kræver også denne tilstand: værten monterer et datasæts snapshot først, efter at containeren er startet. Se ZFS-datasæt.

Repository-stier for sikkerhedskopier defaulter til /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, oprettet ved den første sikkerhedskopi. Skift placeringen når som helst i Indstillinger, Lagring, Sikkerhedskopistier. Hvert stifelt har også en Lokal / Fjern-kontakt lige ved siden af: en sti kan være en restic-remote (s3:..., rest:..., sftp:..., rclone:...) i stedet for en lokal mappe, og så sikkerhedskopieres der direkte dertil uden separat lokal kopi; se Fjernbetjente primære arkiver.

Vært-integrationstjek

Åbn /spike i web-UI'en, når containeren er startet. Den prober hver montering og hvert CLI (Docker-socket, libvirt, restic, qemu-img, rclone) og rapporterer eventuelle manglende dele.

Genkendelse af sikkerhedskopiernes kilder

For hver container vælger BombVault selv, hvilke bind-monteringer og navngivne diskenheder der sikkerhedskopieres. En sti tages med, så snart et af følgende punkter gælder (resultatet kan altid tilsidesættes for den enkelte container under dens Sikkerhedskopierede mapper):

• Match på et datarod-segment: bindets værtskilde indeholder et af segmenterne i DATA_ROOT_SEGMENTS som en hel stikomponent (som standard kun appdata).
• Navngivne Docker-diskenheder tages altid med, fordi de ikke har nogen engangsudgave, og der derfor ikke er noget at filtrere fra, men kun når diskenhedens rigtige lagersti på værten selv kan nås gennem Host Data-monteringen, nøjagtig som enhver anden værtssti, BombVault sikkerhedskopierer. Standarddriveren til lokale diskenheder lægger en diskenhed under dæmonens egen datarod, altså /var/lib/docker/volumes/<navn>/_data, medmindre det er ændret (tjek med docker info -f '{{.DockerRootDir}}'). Det sted er IKKE dækket af den smalle Host Data-montering med én enkelt mappe, som den generiske docker-compose.yml bruger som standard. En diskenhed, der ikke kan nås, springes stiltiende over, det er ikke en fejl. For rent faktisk at sikkerhedskopiere navngivne diskenheder på en generisk vært skal du pege Host Data (og HOST_SOURCE_ROOT) på en fælles overordnet mappe, der også dækker Dockers datarod: afvejningen står i Host Data-kommentaren i compose-filen (Unraid går uden om det ved af samme grund at montere hele /mnt, sin egen almengyldige konvention på øverste niveau).
• Projektmappe for Docker Compose: bærer containeren den sædvanlige etiket com.docker.compose.project.working_dir (sættes automatisk af docker compose up), kommer den mappe også med, uanset om en bind ramte et datarod-segment.
• Tilsidesættelse med etiketten bombvault.data: sæt etiketten bombvault.data=true på en container for at tage ALLE dens bind-monteringer med, til en opsætning som ingen af de to konventioner ovenfor fanger (for eksempel en enkelt bind /srv/plex/config uden Compose-projekt). Enhver ikke-tom værdi ud over false tæller som sand; en manglende etiket eller bombvault.data=false ændrer ingenting.
• Labelen bombvault.dbdump: sæt bombvault.dbdump=false på en container for at slå dens automatiske databasedump fra (0, no og off gør det samme), eller navngiv motoren (postgres, mysql, mariadb) for at dumpe en container, som BombVault ikke genkender af sig selv. Labelen vinder over kontakten på containerens kort, som er den sædvanlige vej på Unraid.

Sikkerhedsmodel

Root-ækvivalent kontrol over værten

Gennem Docker-socket'en kan BombVault stoppe, fjerne og genoprette containere og læse/skrive appdata, og til VM-sikkerhedskopiering logger den ind på værten over SSH (qemu+ssh://, root som standard) for at køre virsh. Enhver, der kan nå dens web-UI, har reelt root på værten.

• Valgfri adgangskodebeskyttelse (Indstillinger, Sikkerhed): sæt en adgangskode for at kræve login, ryd den for at slå fra. Slået fra som standard til brug på et betroet LAN. Adgangskoden gemmes med Argon2id over en værdi peberet med APP_KEY, så en kopieret /config er værdiløs uden nøglen og langsom at angribe med den. En ny adgangskode kræver mindst 12 tegn; en eksisterende kortere virker videre, indtil den ændres. Sessioner er signerede (HMAC afledt af APP_KEY), og en ændret adgangskode gør dem ugyldige; logins er begrænset til fem fejl i minuttet pr. klient.
• Tofaktorgodkendelse (Indstillinger): en tidskode fra en authenticator-app oven i adgangskoden plus otte engangs-gendannelseskoder, der udleveres én gang ved aktivering. Den delte hemmelighed gemmes krypteret med APP_KEY, og det kræver en aktuel kode at slå den fra igen.
• Adgangsnøgler (WebAuthn) har deres eget kort, når en adgangskode er sat. De bruges sammen med adgangskoden og aldrig i stedet for den, så den, der fjerner alle adgangsnøgler, låser ingen ude. De kræver et rigtigt domænenavn og et certifikat, som browseren stoler på. Standardadressen https://<ip>:3443 er netop det, WebAuthn afviser, og kortet siger det i stedet for at tilbyde en knap, der fejler.
• Ændringer kræver JSON. En forespørgsel, der ændrer noget, skal sende Content-Type: application/json og må ikke være markeret som cross-site af browseren, så en side på et andet websted ikke kan få din browser til at ændre indstillinger på en LAN-adresse. Et script, der styrer API'en, sender den header; alt andet afvises med 415.
• Fordi sikringen er et tilvalg, er hele UI'en og API'en (inklusive off-site-opsætningen, manipulationstest-ruterne og gendannelseskittet), når den er usat, tilgængelige for enhver, der kan nå porten. Aktivér sikringen, når off-site, uforanderlige sikkerhedskopier eller kryptering er i brug.
• Kør kun BombVault på et betroet, ikke-eksponeret netværk. For fjernadgang, sæt den bag en reverse proxy, der tilføjer autentificering og TLS. Svar bærer grundlæggende sikkerhedsheaders (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Bag en reverse proxy bærer hver forespørgsel proxyens adresse, så uden TRUSTED_PROXY tæller login-bremsen alle klienter i én pulje, og en angribers fejl låser også dig ude. Angiv proxyen i TRUSTED_PROXY for at få optælling pr. klient tilbage.
• En reverse proxy foran BombVault skal sende headeren Authorization eller X-API-Key videre til /mcp og må ikke buffere svarene, ellers kan assistenter ikke oprette forbindelse. Se MCP-server.
• MCP-endepunktet /mcp svarer 404, indtil der findes en nøgle, eller login via OAuth er slået til, og det beder hver klient om dens nøgle eller token, også når login-adgangskoden er slået fra; ingen adresse er undtaget, heller ikke localhost. Det har ingen værktøjer til at gendanne eller slette, og gendannelse af en konfigurationssikkerhedskopi tilbagekalder alle nøgler. Se MCP-server.
• Med HTTP_ONLY=true mister session-cookien sit Secure-flag (det er nødvendigt for at virke over almindelig HTTP), så aktivér kun adgangskoden bag en TLS-terminerende proxy, hvis fortrolighed betyder noget.
• VM-sikkerhedskopiets SSH-forbindelse stoler på værtsnøglen ved første forbindelse (TOFU) og pinner den derefter. Verificér værtens nøgle out-of-band, hvis din container-til-vært-sti ikke er betroet.
• Sikkerhedskopier er krypteret af restic, når kryptering er aktiveret (Indstillinger; som standard til), med nøglen afledt af APP_KEY.

MCP-server

MCP-serveren kræver ingen miljøvariabel. Du slår den til ved at oprette en nøgle under Indstillinger, Integrationer, MCP-server, og den svarer på /mcp på samme port som webgrænsefladen (for eksempel https://192.168.1.10:3443/mcp). Uden en aktiv nøgle svarer den sti med 404. Klienter, certifikater og grænser er beskrevet på MCP-server.

VM-sikkerhedskopiering over SSH

BombVault sikkerhedskopierer KVM/libvirt-VM'er uden at montere nogen libvirt-sti. Den kører virsh på værten over SSH (qemu+ssh://), så den aldrig kan påvirke din værts-VM Manager.

At montere værtens libvirt-socket i en container er skrøbeligt på Unraid: VM Manager ejer de stier, og at slå "Enable VMs" om kan efterlade libvirt i en tilstand, hvor den ikke kan starte. SSH-nøglen giver root på værten, samme tillidsniveau som den Docker-socket, BombVault allerede bruger.

Hurtig opsætning:

1. Indstillinger, Integrationer, Værts-SSH: kopiér den viste offentlige nøgle.
2. Tilføj den til Unraids /root/.ssh/authorized_keys (også persisteret til flashen, så den overlever genstarter).
3. Klik på Test forbindelse.

Skabelonen tilføjer --add-host=host.docker.internal:host-gateway, så containeren kan nå værten. Sæt LIBVIRT_HOST til din Unraid LAN-IP, hvis det navn ikke resolverer (for eksempel når containeren kører på et brugerdefineret br0.x-netværk). Hvis du ændrede Unraids SSH-port, så sæt LIBVIRT_SSH_PORT til at matche. Live-øjebliksbilleder kræver derudover qemu guest agent i VM'en og disken på /mnt/cache (ikke /mnt/user).

Fuld VM-opsætning og netværksguide

Den komplette trin-for-trin-guide (SSH-aktivering, persistent nøgleautorisering, brugerdefineret-netværks- og VLAN-routing, metode pr. VM og fejlfinding på værtssiden) findes på docs/vm-backup-ssh-setup.md på GitHub.

Off-site-opsætning

Opsæt en off-site-replika på siden Indstillinger, Off-site. Se Off-site og gendannelse for det fulde arbejdsforløb (uforanderlig/append-only, manipulationstest og DR-øvelser). Kort sagt:

• Backends: SMB/CIFS og NFS (montér share'en, og peg en sikkerhedskopisti mod den), native restic-backends uden rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo) eller en hvilken som helst rclone-remote (rclone:<remote>:<bucket>/path). Backblaze B2 har ingen indbygget backend her: nå den via dens S3-endpoint (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), med nøgle-id'et og applikationsnøglen som S3-legitimationsoplysninger.
• Delte cloud-legitimationsoplysninger gemmes krypteret under Indstillinger, Cloud-adgang, Delte cloud-legitimationsoplysninger.
• SSH-destinationer kræver intet installeret på den anden side. sftp: kræver kun en SSH-server. Tilføj den offentlige nøgle fra Indstillinger, Integrationer, Værts-SSH (også på /config/ssh/id_ed25519.pub) til destinationsbrugerens ~/.ssh/authorized_keys.
• Off-site-kopi: BombVault replikerer nye øjebliksbilleder med restic copy på et best-effort-grundlag oven på et (som regel lokalt) primært repo. Hvert domæne har sin egen off-site-tidsplan plus en Replikér nu-knap.
• Flere off-site-destinationer pr. domæne: hvert domæne kan replikere til flere off-site-destinationer på én gang. Tilføj ekstra destinationer på Indstillinger, Off-site, hver med sit eget repository, sin S3-lagringsklasse, sit append-only-flag, sin opbevaring og sit vækstbudget; de replikerer alle på det domænes off-site-tidsplan. En eksisterende enkelt off-site-opsætning overføres som den første destination.
• Destinationer: off-site-destinationer oprettes én gang under Indstillinger, Off-site, Destinationer, gennem en guide, der viser alle understøttede tjenester. Se Destinationer.
• Placering pr. element: hver container, VM og hvert mappesæt tænder Lokal og de mål, der får dets sikkerhedskopier. Indstillinger, Lagring, Standardplaceringer fastsætter det pr. domæne for elementer uden eget valg. Se Placering pr. element.
• Opbevaring pr. kilde: den lokale og off-site-politikken lever begge på Indstillinger, Opbevaring (lad off-site-politikken stå helt-nul for aldrig at auto-trimme off-site-øjebliksbilleder). Kortene Lokal opbevaring og Off-site-opbevaring har hver Opbevaringsregler pr. kilde, som giver containere, VM'er, flash, mapper, ZFS eller selv-backup deres egne opbevaringsregler, for deres lokale backups og for deres off-site-repo. En kilde uden dem følger de fælles, og opbevaringen efter hver backup, off-site-kopien, en manuel oprydning og opbevaringsforhåndsvisningen bruger alle reglerne for den kilde, de arbejder på. Yderligere off-site-mål beholder de regler, der er sat for dem under Indstillinger, Off-site.
• Båndbreddegrænser: begræns restic-upload/download-hastigheden under Indstillinger, Off-site.
• Streaming først: under Indstillinger, Off-site vælger du medieserverne (Plex, Jellyfin og Emby er forvalgt ud fra image-navnet), den sendehastighed hvorfra en server tæller som streamende, upload-grænsen under streaming og hvor længe efter en stream den normale grænse kommer tilbage.
• Kold- og arkivlagringsklasse (S3): for et native S3 off-site-repo, vælg et gendannelses-læsbart niveau (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). rclone-remotes sætter deres klasse i rclone-konfigurationen.
• Fjernprimært i stedet for lokalt: et domænes sikkerhedskopisti kan selv være en af backends ovenfor, uden lokal kopi og uden replikeringstrin. Kontakten Lokal/Fjern ved feltet og dens sikkerhedsindstillinger for båndbredde, append-only og vækstbudget er beskrevet under Fjernbetjente primære arkiver.

Afvigelser

Anomaliregistreringen indstilles i kortet Afvigelser under Indstillinger, Integritet. Hver kontrol gemmer, så snart du ændrer den, og de tre under kontakten er skjult, mens registreringen er slået fra.

Indstilling	Standard	Hvad den gør
Find afvigelser	Til	Sammenligner hver sikkerhedskopi med elementets egen historik. Slået fra kontrolleres intet nyt, og punktet Afvigelser forsvinder fra sidepanelet; kortet linker stadig til tidligere fund.
Følsomhed	Balanceret	Streng melder mindre ændringer, Lempelig kun store.
Send en notifikation for	Kun kritiske fund	Den laveste alvorlighed, der sender en besked via de kanaler, der er sat op under Notifikationer. Gentagne fejlede sikkerhedskopier og dumps og fejlede planlagte gendannelsestjek sender allerede deres egen besked og sendes ikke to gange.
Behold gamle sikkerhedskopier, når en kilde skrumper kraftigt eller omskrives	Til	Så længe et element har et åbent fund for en næsten tom kilde, en kraftig skrumpning eller det meste af dataene gemt igen, lader opbevaring og oprydning elementets gamle sikkerhedskopier være. Kvittér for fundet eller markér det som forventet for at frigive dem.

Hvert element kan have sin egen følsomhed og sit eget notifikationsminimum. Indstil dem på siden Afvigelser, hvor et element med åbne fund har dem under Overvågning på sit kort, og hvert andet element åbner dem fra kortet Intet åbent, eller i elementets eget panel: mappeafsnittet for en container og indstillingerne for en VM (begge i avanceret tilstand), mappeeditoren for et mappesæt og siderne Flash og Auto-sikkerhedskopi. For et ZFS-element findes de i elementets editor på siden ZFS og gælder for hvert datasæt i dets træ.

Bærbare indstillinger (eksportér og importér)

Kortet Eksportér / importér indstillinger på siden Indstillinger, System skriver hele din BombVault-konfiguration (domæneindstillinger, off-site-destinationer, tidsplaner, opbevaring, notifikationer) til en bærbar JSON-fil, du kan importere på en anden instans, så et flyt til en ny boks eller kloning af en opsætning ikke betyder at genindtaste alt manuelt. Import viser en forhåndsvisning og beder om bekræftelse, og den rører aldrig dine sikkerhedskopidata eller -historik.

Eksporten kan indeholde legitimationsoplysninger

Du vælger, om off-site-, notifikations- og MQTT-broker-legitimationsoplysninger skal medtages i filen. Med legitimationsoplysninger medtaget er eksporten lige så følsom som dit gendannelseskit, så opbevar den et sikkert sted. Uden dem indeholder filen kun ikke-hemmelige indstillinger.