Konfigurasjon

Denne siden dekker containerens miljøvariabler, monteringene malen tilbyr, VM-sikkerhetskopiering over SSH og oppsettet for ekstern lagring. Sikkerhetskopi-repository-stier konfigureres inne i appen (Innstillinger, Lagring, Sikkerhetskopistier), ikke via miljøvariabler.

Miljøvariabler

Variabel	Påkrevd	Beskrivelse
APP_KEY	Ja	32-byte hex-hemmelighet (64 hex-tegn) brukt til å utlede passordet til restic-repoet. Generer med openssl rand -hex 32. Hold dette trygt: mister du det, blir krypterte sikkerhetskopier umulige å gjenopprette.
LIBVIRT_HOST	For VM-er	Unraid-host nådd over SSH for VM-sikkerhetskopiering (standard host.docker.internal; malen forhåndsutfyller en LAN-IP-plassholder). Bruk din Unraid-LAN-IP, påkrevd på et egendefinert br0.x-nettverk. Brukes også til sikkerhetskopi av ZFS-datasett (malfelt Host SSH: Address); plassholderen 192.168.x.x regnes som ikke satt.
LIBVIRT_SSH_PORT	Nei	Host-SSH-port for VM-sikkerhetskopiering (standard 22). Malfelt Host SSH: Port, også for ZFS-datasett.
LIBVIRT_SSH_USER	Nei	SSH-bruker på hosten for VM-sikkerhetskopiering (standard root). Malfelt Host SSH: User, også for ZFS-datasett.
LIBVIRT_URI	Nei	Full libvirt-tilkoblings-URI, brukt ordrett i stedet for å bygge en fra de tre LIBVIRT_*-variablene over (som da ignoreres for tilkoblingsstrengen). Ikke satt som standard. Nødvendig på TrueNAS Scale, der libvirtd lytter på en ikke-standard socket som den bygde strengformen ikke kan uttrykke: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Se TrueNAS Scale-delen i docs/vm-backup-ssh-setup.md. Er det en qemu+ssh://-URI, hentes hver av LIBVIRT_HOST, LIBVIRT_SSH_USER og LIBVIRT_SSH_PORT som ikke er satt, fra den, også for BombVaults egne SSH-kommandoer (NVRAM-overføring, ZFS-datasett).
PORT	Nei	HTTP-port (standard 3000; brukes kun med HTTP_ONLY=true).
HTTPS_PORT	Nei	HTTPS-port (standard 3443; malen publiserer den 1:1, så WebUI-en svarer på https://<ip>:3443).
HTTP_ONLY	Nei	Sett true for å deaktivere den selvsignerte HTTPS-lytteren og kun servere ren HTTP (til bruk bak en TLS-terminerende revers-proxy).
BIND_HOST	Nei	Adressen WebUI-en lytter på (standard 0.0.0.0, alle grensesnitt). La den stå usatt i containeren, der de publiserte portene trenger alle grensesnitt; 127.0.0.1 passer for en kjøring utenfor Docker. Helsesjekken spør på samme adresse.
TRUSTED_PROXY	Nei	Kommaseparerte adresser eller CIDR-områder for omvendt proxy foran BombVault (for eksempel 192.168.20.11 eller 10.0.0.0/8). Bare fra disse hoppene tros X-Forwarded-For, og påloggingsbremsen teller da feil per ekte klient i stedet for å samle alle bak proxyen i én bøtte. Ikke satt (standard) betyr at ingen tros: en betingelsesløst trodd header ville la enhver kaller velge sin egen bøtte.
HOST_SOURCE_ROOT	Nei	Host-stien montert som Host Data (standard /mnt). BombVault oversetter bind-monterings-kildene Docker rapporterer til stier under denne monteringen. Endre kun hvis du monterte en annen host-rot.
DATA_ROOT_SEGMENTS	Nei	Kommaseparerte sti-segmentnavn som markerer en bind-monterings-kilde som sikkerhetskopidata (standard appdata, i tråd med Unraids /mnt/user/appdata/<container>-konvensjon). En containers bind-montering velges automatisk for sikkerhetskopiering når ETHVERT oppført segment forekommer som et fullt sti-segment i host-kilden dens. DATA_ROOT_SEGMENTS=appdata,config plukker for eksempel også opp en .../config-binding. Se Oppdagelse av sikkerhetskopikilder for de andre, alltid-aktive måtene en containers datamappe blir funnet på.
PLATFORM	Nei	Tvinger hvilken plattform BombVault oppfatter seg selv som å kjøre på, i stedet for å auto-oppdage: unraid, generic, eller truenas (ikke satt som standard: auto-oppdager Unraid ved å sondere etter dockerMan-markøren under flash-monteringen, ellers generic; en ukjent verdi faller også tilbake til generic, logget). Sett den eksplisitt på en generisk Docker-host eller TrueNAS Scale i stedet for å stole på auto-sonderingen som er forbeholdt Unraid; det gjør den generiske compose-filen. Endrer appdata-fallback-konvensjonen, standardene for gjenopprettingsmål på tvers av instanser, og om varslings- og følgesvenn-plugin-trinnene som er forbeholdt Unraid i det hele tatt forsøkes (se internal/platform).
BOMBVAULT_SELF_CONTAINER	Nei	Navnet på selve BombVault-containeren, så den aldri sikkerhetskopierer (og dermed stopper) seg selv.
BACKUP_MAX_HOURS	Nei	Maksimalt antall klokketimer en enkelt sikkerhetskopieringskjøring kan holde domenelåsen sin før den tvangsavbrytes (en beskyttelse så en fastkjørt kjøring ikke kan blokkere domenet for alltid). Tom (standard) bruker 48. Hev den for svært store eller trege sky-sikkerhetskopier (en kjøring avbrutt ved taket feiler med context deadline exceeded). Sett 0 for å deaktivere taket helt.
BACKUP_STALL_HOURS	Nei	Timer en sikkerhetskopiering kan gå helt uten fremdrift før den avbrytes. Tom (standard) bruker 2; sett 0 for aldri å avbryte ved stillstand. Dette er den finere av de to beskyttelsene og som regel den som slår til: den følger med på om noe fortsatt skjer, ikke på hvor lenge kjøringen har pågått, så en treg men frisk sikkerhetskopiering på flere terabyte får være i fred, mens en som henger på en deling som ikke svarer, stoppes etter timer i stedet for dager. En advarsel logges etter 30 minutter med stillhet, før noe avbrytes. Skanning teller som fremdrift: restic skriver ingen byte mens det går gjennom et stort tre, og den fasen overvåkes via totalene for filer og byte i stedet for via skrevne byte. De to variablene er uavhengige, og BACKUP_MAX_HOURS begrenser fortsatt fasene etter selve sikkerhetskopieringen (oppbevaring, statistikk, ekstern kopi), der det ikke finnes tellere å følge med på.
DB_DUMP_MAX_HOURS	Nei	Timer én automatisk databasedump får kjøre før den stoppes. Tomt (standard) bruker 6; tillatte verdier er 1 til 48, og grensen holdes en time under BACKUP_MAX_HOURS (på halvparten av den når den er under to timer), slik at en lang dump kuttes av sin egen grense og meldes som det, i stedet for å dra sikkerhetskopien med seg. En dump som ikke kommer videre, stoppes tidligere, etter BACKUP_STALL_HOURS. En stoppet dump feiler for seg selv, og sikkerhetskopien av containeren fortsetter. På Unraid legger du variabelen til BombVault-containeren med Add another Path, Port, Variable.
TZ	Nei	Tidssone for planleggeren (for eksempel Europe/Berlin). Hvis den ikke settes, kjører alle planer i UTC: en plan satt til 02:30 starter da 02:30 UTC og ikke etter lokal tid. På Unraid setter du aldri dette selv: systemet sender sin egen tidssone videre til hver container. Oppstartsloggen viser hvilken sone som ble funnet. En sone med sommertid hopper over én kjøring om våren og kjører én to ganger om høsten, mens UTC ikke gjør noe av det, men til gjengjeld forskyves en time mot klokken din to ganger i året.

Monteringer

Monter Docker-socketen, flashen (/boot) og Host Data-roten (/mnt) som vist i CA-malen. Sikkerhetskopi-kilder og -destinasjoner ligger begge under Host Data, og den er montert slave så en fjerndeling som monteres etter at containeren starter (for eksempel under /mnt/remotes) blir synlig uten en omstart.

Sikkerhetskopi av ZFS-datasett trenger også denne modusen: verten monterer øyeblikksbildet av et datasett først etter at containeren har startet. Se ZFS-datasett.

Sikkerhetskopi-repository-stier har som standard /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, opprettet ved den første sikkerhetskopieringen. Endre plasseringen når som helst i Innstillinger, Lagring, Sikkerhetskopistier. Hvert stifelt har også en Lokal / Ekstern-bryter rett ved siden av: en sti kan være en restic-remote (s3:..., rest:..., sftp:..., rclone:...) i stedet for en lokal mappe, og da sikkerhetskopieres det rett dit uten egen lokal kopi; se Eksterne primære arkiver.

Host-integrasjonssjekk

Åpne /spike i webgrensesnittet etter at containeren har startet. Den sonderer hver montering og hvert CLI (Docker-socket, libvirt, restic, qemu-img, rclone) og rapporterer manglende deler.

Gjenkjenning av sikkerhetskopiens kilder

For hver container velger BombVault selv hvilke bind-monteringer og navngitte volumer som sikkerhetskopieres. En sti tas med så snart ett av punktene nedenfor gjelder (resultatet kan alltid overstyres per container under dens Sikkerhetskopierte mapper):

• Treff på et datarot-segment: bindens vertskilde inneholder ett av segmentene i DATA_ROOT_SEGMENTS som en hel stikomponent (som standard bare appdata).
• Navngitte Docker-volumer tas alltid med, fordi de ikke har noen engangsutgave og det dermed ikke er noe å filtrere bort, men bare når volumets virkelige lagringssti på verten selv er nåbar gjennom Host Data-monteringen, akkurat som enhver annen vertssti BombVault sikkerhetskopierer. Standarddriveren for lokale volumer legger et volum under selve demonens datarot, altså /var/lib/docker/volumes/<navn>/_data med mindre det er endret (sjekk med docker info -f '{{.DockerRootDir}}'). Det stedet er IKKE dekket av den smale Host Data-monteringen med én enkelt katalog som den generiske docker-compose.yml bruker som standard. Et volum som ikke kan nås, hoppes stille over, det er ingen feil. For faktisk å sikkerhetskopiere navngitte volumer på en generisk vert må du peke Host Data (og HOST_SOURCE_ROOT) mot en felles overordnet katalog som også dekker Dockers datarot: avveiningen står i Host Data-kommentaren i compose-filen (Unraid går utenom dette ved av samme grunn å montere hele /mnt, sin egen allmenngyldige konvensjon på øverste nivå).
• Prosjektkatalog for Docker Compose: bærer containeren den vanlige etiketten com.docker.compose.project.working_dir (settes automatisk av docker compose up), blir den katalogen også lagt til, uavhengig av om noen bind traff et datarot-segment.
• Overstyring med etiketten bombvault.data: sett etiketten bombvault.data=true på en container for å ta med ALLE dens bind-monteringer, for et oppsett som ingen av konvensjonene over fanger opp (for eksempel én enkelt bind /srv/plex/config uten Compose-prosjekt). Enhver ikke-tom verdi utenom false teller som sann; en manglende etikett eller bombvault.data=false endrer ingenting.
• Etiketten bombvault.dbdump: sett bombvault.dbdump=false på en container for å slå av den automatiske databasedumpen (0, no og off gjør det samme), eller navngi motoren (postgres, mysql, mariadb) for å dumpe en container BombVault ikke gjenkjenner selv. Etiketten vinner over bryteren på containerens kort, som er den vanlige veien på Unraid.

Sikkerhetsmodell

Root-ekvivalent kontroll over hosten

Gjennom Docker-socketen kan BombVault stoppe, fjerne og gjenskape containere og lese/skrive appdata, og for VM-sikkerhetskopiering logger den seg inn på hosten over SSH (qemu+ssh://, root som standard) for å kjøre virsh. Alle som når webgrensesnittet, har i praksis root på hosten.

• Valgfri passordbeskyttelse (Innstillinger, Sikkerhet): sett et passord for å kreve pålogging, tøm det for å slå av. Av som standard for bruk på et betrodd LAN. Passordet lagres med Argon2id over en verdi pepret med APP_KEY, så en kopiert /config er verdiløs uten nøkkelen og treg å angripe med den. Et nytt passord krever minst 12 tegn; et eksisterende kortere fungerer videre til det endres. Økter er signert (HMAC utledet fra APP_KEY), og en passordendring gjør dem ugyldige; pålogginger er begrenset til fem feil i minuttet per klient.
• Tofaktorautentisering (Innstillinger): en tidskode fra en autentiseringsapp i tillegg til passordet, pluss åtte engangs gjenopprettingskoder som deles ut én gang når den slås på. Den delte hemmeligheten lagres kryptert med APP_KEY, og det kreves en gyldig kode for å slå den av igjen.
• Passnøkler (WebAuthn) har sitt eget kort når et passord er satt. De brukes sammen med passordet og aldri i stedet for det, så den som fjerner alle passnøkler, låser ingen ute. De krever et ekte domenenavn og et sertifikat som nettleseren stoler på. Standardadressen https://<ip>:3443 er nettopp det WebAuthn avviser, og kortet sier det i stedet for å tilby en knapp som feiler.
• Endringer krever JSON. En forespørsel som endrer noe, må sende Content-Type: application/json og kan ikke være merket som cross-site av nettleseren, slik at en side på et annet nettsted ikke kan få nettleseren din til å endre innstillinger på en LAN-adresse. Et skript som styrer API-et, sender den headeren; alt annet avvises med 415.
• Fordi porten er valgfri, er hele grensesnittet og API-et (inkludert ekstern-oppsettet, tamper-test-rutene og gjenopprettingssettet) tilgjengelig for alle som når porten når den ikke er satt. Aktiver porten så snart ekstern lagring, uforanderlige sikkerhetskopier eller kryptering er i bruk.
• Kjør BombVault kun på et betrodd, ikke-eksponert nettverk. For fjerntilgang, sett den bak en revers-proxy som legger til autentisering og TLS. Svar bærer grunnleggende sikkerhetsheadere (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Bak en omvendt proxy bærer hver forespørsel proxyens adresse, så uten TRUSTED_PROXY teller påloggingsbremsen alle klienter i én bøtte, og en angripers feil låser deg også ute. Oppgi proxyen i TRUSTED_PROXY for å få telling per klient tilbake.
• En omvendt proxy foran BombVault må sende headeren Authorization eller X-API-Key videre til /mcp og må ikke bufre svarene, ellers kan ikke assistenter koble til. Se MCP-server.
• MCP-endepunktet /mcp svarer 404 til det finnes en nøkkel eller pålogging via OAuth er slått på, og det krever nøkkel eller token av hver klient, også når påloggingspassordet er slått av; ingen adresse er unntatt, heller ikke localhost. Det har ingen verktøy for å gjenopprette eller slette, og gjenoppretting av en konfigurasjonssikkerhetskopi tilbakekaller alle nøkler. Se MCP-server.
• Med HTTP_ONLY=true mister øktinformasjonskapselen sitt Secure-flagg (det må den, for å fungere over ren HTTP), så aktiver bare passordet bak en TLS-terminerende proxy hvis konfidensialitet betyr noe.
• VM-sikkerhetskopi-SSH-tilkoblingen stoler på host-nøkkelen ved første tilkobling (TOFU) og fester den deretter. Verifiser hostens nøkkel utenfor båndet hvis container-til-host-veien din ikke er betrodd.
• Sikkerhetskopier krypteres av restic når kryptering er aktivert (Innstillinger; på som standard), med nøkkelen utledet fra APP_KEY.

MCP-server

MCP-serveren trenger ingen miljøvariabel. Du slår den på ved å lage en nøkkel under Innstillinger, Integrasjoner, MCP-server, og den svarer på /mcp på samme port som webgrensesnittet (for eksempel https://192.168.1.10:3443/mcp). Uten en aktiv nøkkel svarer den stien med 404. Klienter, sertifikater og grenser er beskrevet på MCP-server.

VM-sikkerhetskopiering over SSH

BombVault sikkerhetskopierer KVM/libvirt-VM-er uten å montere noen libvirt-sti. Den kjører virsh på hosten over SSH (qemu+ssh://), så den kan aldri påvirke host-VM Manageren din.

Å montere hostens libvirt-socket i en container er skjørt på Unraid: VM Manager eier de stiene, og å slå "Enable VMs" av og på kan etterlate libvirt i en tilstand der den ikke starter. SSH-nøkkelen gir root på hosten, samme tillitsnivå som Docker-socketen BombVault allerede bruker.

Rask oppsett:

1. Innstillinger, Integrasjoner, Verts-SSH: kopier den viste offentlige nøkkelen.
2. Legg den til i Unraids /root/.ssh/authorized_keys (også lagret til flashen så den overlever omstarter).
3. Klikk Test tilkobling.

Malen legger til --add-host=host.docker.internal:host-gateway så containeren kan nå hosten. Sett LIBVIRT_HOST til din Unraid-LAN-IP hvis det navnet ikke løses (for eksempel når containeren kjører på et egendefinert br0.x-nettverk). Hvis du endret Unraids SSH-port, sett LIBVIRT_SSH_PORT til å matche. Live-øyeblikksbilder trenger i tillegg qemu guest agent i VM-en og disken på /mnt/cache (ikke /mnt/user).

Full VM-oppsetts- og nettverksveiledning

Den fullstendige trinn-for-trinn-veiledningen (SSH-aktivering, vedvarende nøkkelautorisasjon, egendefinert-nettverk og VLAN-ruting, metode per VM og host-side-feilsøking) ligger på docs/vm-backup-ssh-setup.md på GitHub.

Oppsett for ekstern lagring

Sett opp en ekstern replika på Innstillinger, Off-site-siden. Se Ekstern lagring og gjenoppretting for hele arbeidsflyten (uforanderlig/append-only, tamper-testing og DR-øvelser). I korthet:

• Backender: SMB/CIFS og NFS (monter delingen og pek en sikkerhetskopisti mot den), native restic-backender uten 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 innebygd backend her: nå den via S3-endepunktet (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), med nøkkel-ID-en og applikasjonsnøkkelen som S3-legitimasjon.
• Delt skylegitimasjon lagres kryptert under Innstillinger, Skytilgang, Delt skylegitimasjon.
• SSH-mål trenger ingenting installert på den andre siden. sftp: trenger bare en SSH-server. Legg til den offentlige nøkkelen fra Innstillinger, Integrasjoner, Verts-SSH (også på /config/ssh/id_ed25519.pub) til målbrukerens ~/.ssh/authorized_keys.
• Ekstern kopi: BombVault replikerer nye øyeblikksbilder med restic copy på best-effort-basis, i tillegg til et (vanligvis lokalt) primært repo. Hvert domene har sin egen eksterne tidsplan, pluss en Replikér nå-knapp.
• Flere eksterne mål per domene: hvert domene kan replikere til flere eksterne destinasjoner samtidig. Legg til ekstra mål på Innstillinger, Off-site, hvert med sitt eget repository, sin S3-lagringsklasse, append-only-flagg, oppbevaring og vekstbudsjett; de replikerer alle på det domenets eksterne tidsplan. Et eksisterende enkelt ekstern-oppsett overføres som det første målet.
• Mål: eksterne mål settes opp én gang under Innstillinger, Off-site, Mål, gjennom en veiviser som lister hver støttede tjeneste. Se Mål.
• Plassering per element: hver container, VM og hvert filsett tenner Lokal og målene som får sikkerhetskopiene dets. Innstillinger, Lagring, Standardplasseringer bestemmer dette per domene for elementer uten eget valg. Se Plassering per element.
• Oppbevaring per kilde: både den lokale og den eksterne policyen ligger på Innstillinger, Oppbevaring (la den eksterne policyen stå helt på null for aldri å auto-trimme eksterne øyeblikksbilder). Kortene Lokal oppbevaring og Off-site-oppbevaring har hver Oppbevaringsregler per kilde, som gir containere, VM-er, flash, mapper, ZFS eller selv-backupen egne oppbevaringsregler, for de lokale sikkerhetskopiene og for det eksterne repoet deres. En kilde uten egne regler følger de felles, og oppbevaringen etter hver sikkerhetskopi, den eksterne kopien, en manuell opprydding og forhåndsvisningen av oppbevaring bruker alle reglene til kilden de jobber med. Flere eksterne mål beholder reglene som er satt for dem under Innstillinger, Ekstern.
• Båndbreddegrenser: begrens resticts opplastings-/nedlastingshastighet under Innstillinger, Off-site.
• Strømming først: under Innstillinger, Off-site velger du medieserverne (Plex, Jellyfin og Emby er forhåndsvalgt ut fra image-navnet), sendehastigheten der en server regnes som strømmende, opplastingsgrensen under strømming og hvor lenge etter en strøm den vanlige grensen kommer tilbake.
• Kald og arkiv-lagringsklasse (S3): for et native S3-eksternt repo, velg et gjenopprettingslesbart nivå (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). rclone-remoter setter klassen sin i rclone-konfigurasjonen.
• Eksternt primærrepo i stedet for lokalt: et domenes sikkerhetskopisti kan selv være en av backendene over, uten lokal kopi og uten replikeringssteg. Bryteren Lokal/Ekstern ved feltet og sikkerhetsinnstillingene for båndbredde, append-only og vekstbudsjett er beskrevet under Eksterne primære arkiver.

Avvik

Avviksoppdagelsen stilles inn i kortet Avvik under Innstillinger, Integritet. Hver kontroll lagres så snart du endrer den, og de tre under bryteren er skjult mens oppdagelsen er slått av.

Innstilling	Standard	Hva den gjør
Oppdag avvik	På	Sammenligner hver sikkerhetskopi med elementets egen historikk. Slått av kontrolleres ingenting nytt, og oppføringen Avvik forsvinner fra sidepanelet; kortet lenker fortsatt til tidligere funn.
Følsomhet	Balansert	Streng melder mindre endringer, Romslig bare store.
Send varsel for	Bare kritiske funn	Den laveste alvorlighetsgraden som sender en melding via kanalene som er satt opp under Varsler. Gjentatte mislykkede sikkerhetskopier og dumper og mislykkede planlagte gjenopprettingskontroller sender allerede en egen melding og sendes ikke to ganger.
Behold gamle sikkerhetskopier når en kilde krymper kraftig eller skrives om	På	Så lenge et element har et åpent funn for en nesten tom kilde, en kraftig krymping eller det meste av dataene lagret på nytt, lar oppbevaring og opprydding elementets gamle sikkerhetskopier være. Kvitter for funnet eller merk det som forventet for å slippe dem.

Hvert element kan ha sin egen følsomhet og sitt eget varslingsminimum. Still dem inn på siden Avvik, der et element med åpne funn har dem under Overvåking på kortet sitt, og alle andre elementer åpner dem fra kortet Ingenting åpent, eller i elementets eget panel: mappedelen for en container og innstillingene for en VM (begge i avansert modus), mappeeditoren for et mappesett og sidene Flash og Auto-sikkerhetskopi. For et ZFS-element ligger de i elementets redigering på siden ZFS og gjelder for hvert datasett i treet.

Portable innstillinger (eksporter og importer)

Kortet Eksporter / importer innstillinger på siden Innstillinger, System skriver hele BombVault-konfigurasjonen din (domeneinnstillinger, eksterne mål, tidsplaner, oppbevaring, varsler) til en portabel JSON-fil du kan importere på en annen instans, så å flytte til en ny boks eller klone et oppsett ikke betyr å taste inn alt på nytt for hånd. Import viser en forhåndsvisning og ber om bekreftelse, og den rører aldri sikkerhetskopidataene eller -historikken din.

Eksporten kan inneholde legitimasjon

Du velger om du vil inkludere ekstern-, varslings- og MQTT-megler-legitimasjonen i filen. Med legitimasjon inkludert er eksporten like sensitiv som gjenopprettingssettet ditt, så oppbevar den et trygt sted. Uten dem inneholder filen kun ikke-hemmelige innstillinger.