Konfiguration

Den här sidan täcker containerns miljövariabler, monteringarna som mallen tillhandahåller, VM-säkerhetskopiering över SSH och off-site-uppsättningen. Säkerhetskopieringens repository-sökvägar konfigureras inuti appen (Inställningar, Lagring, Säkerhetskopiesökvägar), inte via miljövariabler.

Miljövariabler

Variabel	Obligatorisk	Beskrivning
APP_KEY	Ja	32-byte hex-hemlighet (64 hex-tecken) som används för att härleda restic-repo-lösenordet. Generera med openssl rand -hex 32. Förvara den säkert: att förlora den gör krypterade säkerhetskopior oåterställbara.
LIBVIRT_HOST	För VM:ar	Unraid-värd nådd över SSH för VM-säkerhetskopiering (standard host.docker.internal; mallen förifyller en LAN-IP-platshållare). Använd din Unraid-LAN-IP, obligatorisk på ett anpassat br0.x-nätverk. Används också för säkerhetskopior av ZFS-datauppsättningar (mallfält Host SSH: Address); platshållaren 192.168.x.x räknas som inte satt.
LIBVIRT_SSH_PORT	Nej	Värdens SSH-port för VM-säkerhetskopiering (standard 22). Mallfält Host SSH: Port, även för ZFS-datauppsättningar.
LIBVIRT_SSH_USER	Nej	SSH-användare på värden för VM-säkerhetskopiering (standard root). Mallfält Host SSH: User, även för ZFS-datauppsättningar.
LIBVIRT_URI	Nej	Fullständig anslutnings-URI för libvirt, används ordagrant i stället för att bygga en från de tre LIBVIRT_*-variablerna ovan (som då ignoreras för anslutningssträngen). Inte satt som standard. Behövs på TrueNAS Scale, vars libvirtd lyssnar på en icke-standardsocket som den sammansatta strängformen inte kan uttrycka: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Se TrueNAS Scale-avsnittet i docs/vm-backup-ssh-setup.md. Är det en qemu+ssh://-URI hämtas var och en av LIBVIRT_HOST, LIBVIRT_SSH_USER och LIBVIRT_SSH_PORT som inte är satt från den, även för BombVaults egna SSH-kommandon (NVRAM-överföring, ZFS-datauppsättningar).
PORT	Nej	HTTP-port (standard 3000; används endast med HTTP_ONLY=true).
HTTPS_PORT	Nej	HTTPS-port (standard 3443; mallen publicerar den 1:1, så WebUI svarar på https://<ip>:3443).
HTTP_ONLY	Nej	Sätt true för att inaktivera den självsignerade HTTPS-lyssnaren och servera enbart vanlig HTTP (för användning bakom en TLS-terminerande reverse proxy).
BIND_HOST	Nej	Adressen som WebUI lyssnar på (standard 0.0.0.0, alla gränssnitt). Lämna den osatt i containern, vars publicerade portar behöver alla gränssnitt; 127.0.0.1 passar för en körning utanför Docker. Healthchecken frågar samma adress.
TRUSTED_PROXY	Nej	Kommaseparerade adresser eller CIDR-intervall för den omvända proxyn framför BombVault (till exempel 192.168.20.11 eller 10.0.0.0/8). Endast från dessa hopp tros X-Forwarded-For, och inloggningsbromsen räknar då misslyckanden per verklig klient i stället för att lägga alla bakom proxyn i samma hink. Osatt (standard) betyder att ingen tros: en villkorslöst trodd rubrik skulle låta vem som helst välja sin egen hink.
HOST_SOURCE_ROOT	Nej	Värdsökvägen monterad som Host Data (standard /mnt). BombVault översätter de bind-monteringskällor Docker rapporterar till sökvägar under den här monteringen. Ändra endast om du monterade en annan värdrot.
DATA_ROOT_SEGMENTS	Nej	Kommaseparerade sökvägssegmentnamn som markerar en bind-monteringskälla som säkerhetskopieringsdata (standard appdata, vilket matchar Unraids /mnt/user/appdata/<container>-konvention). En containers bind-montering väljs automatiskt för säkerhetskopiering när NÅGOT listat segment förekommer som ett fullständigt sökvägssegment i dess värdkälla, till exempel plockar DATA_ROOT_SEGMENTS=appdata,config även upp en .../config-bindning. Se Identifiering av säkerhetskopieringskällor för de andra, alltid aktiva sätten en containers datamapp hittas på.
PLATFORM	Nej	Tvingar vilken plattform BombVault uppfattar sig själv som att köra på, i stället för att identifiera den automatiskt: unraid, generic eller truenas (standard inte satt: identifierar Unraid automatiskt genom att sondera efter dess dockerMan-markör under flash-monteringen, annars generic; ett okänt värde faller också tillbaka till generic, vilket loggas). Sätt den explicit på en generisk Docker-värd eller TrueNAS Scale i stället för att förlita dig på den Unraid-specifika autosonderingen, vilket den generiska compose-filen gör. Ändrar reservkonventionen för appdata, standardmålen för återställning mellan instanser, och om de Unraid-specifika stegen för aviseringar och kompanjonsplugin ens försöks (se internal/platform).
BOMBVAULT_SELF_CONTAINER	Nej	Namnet på själva BombVault-containern, så att den aldrig säkerhetskopierar (och därmed stoppar) sig själv.
BACKUP_MAX_HOURS	Nej	Maximalt antal väggklockstimmar en enskild säkerhetskopieringskörning får hålla sitt domänlås innan den tvingas avbrytas (ett skydd så att en fastnad körning inte kan blockera domänen för alltid). Tomt (standard) använder 48. Höj det för mycket stora eller långsamma molnsäkerhetskopior (en körning som avbryts vid taket misslyckas med context deadline exceeded). Sätt 0 för att inaktivera taket helt.
BACKUP_STALL_HOURS	Nej	Timmar en säkerhetskopiering får gå helt utan framsteg innan den avbryts. Tomt (standard) använder 2; sätt 0 för att aldrig avbryta vid stillastående. Det här är det finare av de två skydden och oftast det som slår till: det bevakar om något fortfarande händer, inte hur länge körningen har pågått, så en långsam men frisk säkerhetskopiering på flera terabyte lämnas i fred, medan en som har fastnat på en resurs som inte svarar stoppas efter timmar i stället för dagar. En varning loggas efter 30 minuters tystnad, innan något avbryts. Skanning räknas som framsteg: restic skriver inga byte medan det går igenom ett stort träd, och den fasen bevakas via summorna för filer och byte i stället för via skrivna byte. De två variablerna är oberoende av varandra, och BACKUP_MAX_HOURS begränsar fortfarande faserna efter själva säkerhetskopieringen (gallring, statistik, off-site-kopia), där det inte finns några räknare att bevaka.
DB_DUMP_MAX_HOURS	Nej	Timmar som en automatisk databasdump får köra innan den stoppas. Tomt (standard) använder 6; tillåtna värden är 1 till 48, och gränsen hålls en timme under BACKUP_MAX_HOURS (på hälften av den när den är under två timmar), så att en lång dump kapas av sin egen gräns och rapporteras som det i stället för att dra med sig säkerhetskopian. En dump som slutar göra framsteg stoppas tidigare, efter BACKUP_STALL_HOURS. En stoppad dump misslyckas för sig själv och containerns säkerhetskopiering fortsätter. På Unraid lägger du till variabeln på BombVault-containern med Add another Path, Port, Variable.
TZ	Nej	Tidszon för schemaläggaren (till exempel Europe/Berlin). Om den inte anges körs alla scheman i UTC: ett schema satt till 02:30 startar då 02:30 UTC och inte enligt lokal tid. På Unraid ställer du aldrig in detta själv: systemet skickar sin egen tidszon till varje container. Startloggen visar vilken zon som användes. En zon med sommartid hoppar över en körning på våren och kör en två gånger på hösten, medan UTC inte gör något av det men i stället förskjuts en timme mot din klocka två gånger om året.

Monteringar

Montera Docker-socketen, flashen (/boot) och Host Data-roten (/mnt) som visas i CA-mallen. Både säkerhetskopieringens källor och mål ligger under Host Data, och den monteras slave så att en fjärresurs som monteras efter att containern startat (till exempel under /mnt/remotes) blir synlig utan en omstart.

Säkerhetskopior av ZFS-datauppsättningar behöver också det här läget: värden monterar en uppsättnings ögonblicksbild först efter att containern har startat. Se ZFS-datauppsättningar.

Säkerhetskopieringens repository-sökvägar har standardvärdet /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, skapade vid den första säkerhetskopieringen. Ändra platsen när som helst i Inställningar, Lagring, Säkerhetskopiesökvägar. Varje sökvägsfält har också en omkopplare Lokal / Fjärran alldeles intill: en sökväg kan vara en restic-fjärr (s3:..., rest:..., sftp:..., rclone:...) i stället för en lokal mapp, och då säkerhetskopieras det direkt dit utan separat lokal kopia; se Fjärranslutna primära arkiv.

Värdintegrationskontroll

Öppna /spike i webbgränssnittet efter att containern startat. Den sonderar varje montering och CLI (Docker-socket, libvirt, restic, qemu-img, rclone) och rapporterar eventuella saknade delar.

Igenkänning av säkerhetskopieringens källor

För varje container väljer BombVault själv vilka bind-monteringar och namngivna volymer som ska säkerhetskopieras. En sökväg tas med så snart någon av följande punkter gäller (resultatet kan alltid skrivas över per container under dess Säkerhetskopierade mappar):

• Träff på ett datarot-segment: bindens värdkälla innehåller något av segmenten i DATA_ROOT_SEGMENTS som en fullständig sökvägsdel (som standard endast appdata).
• Namngivna Docker-volymer tas alltid med, eftersom de saknar en slängbar motsvarighet och det därmed inte finns något att filtrera bort, men bara när volymens verkliga lagringssökväg på värden själv går att nå genom Host Data-monteringen, precis som varje annan värdsökväg BombVault säkerhetskopierar. Standarddrivrutinen för lokala volymer lägger en volym under demonens egen datarot, alltså /var/lib/docker/volumes/<namn>/_data om inget ändrats (kontrollera med docker info -f '{{.DockerRootDir}}'). Den platsen omfattas INTE av den smala Host Data-monteringen med en enda katalog som den generiska docker-compose.yml använder som standard. En onåbar volym hoppas tyst över, det är inget fel. För att verkligen säkerhetskopiera namngivna volymer på en generisk värd, rikta Host Data (och HOST_SOURCE_ROOT) mot en gemensam överordnad katalog som även täcker Dockers datarot: avvägningen står i Host Data-kommentaren i compose-filen (Unraid kringgår detta genom att av samma skäl montera hela /mnt, sin egen allmängiltiga konvention på översta nivån).
• Projektkatalog för Docker Compose: bär containern den vanliga etiketten com.docker.compose.project.working_dir (sätts automatiskt av docker compose up) läggs även den katalogen till, oavsett om någon bind matchade ett datarot-segment.
• Åsidosättning med etiketten bombvault.data: sätt etiketten bombvault.data=true på en container för att ta med ALLA dess bind-monteringar, för en uppställning som ingen av konventionerna ovan fångar (till exempel en enda bind /srv/plex/config utan Compose-projekt). Varje icke-tomt värde utom false räknas som sant; en saknad etikett eller bombvault.data=false ändrar ingenting.
• Etiketten bombvault.dbdump: sätt bombvault.dbdump=false på en container för att stänga av dess automatiska databasdump (0, no och off gör detsamma), eller namnge motorn (postgres, mysql, mariadb) för att dumpa en container som BombVault inte känner igen på egen hand. Etiketten går före reglaget på containerns kort, som är den vanliga vägen på Unraid.

Säkerhetsmodell

Root-likvärdig kontroll över värden

Via Docker-socketen kan BombVault stoppa, ta bort och återskapa containrar och läsa/skriva appdata, och för VM-säkerhetskopiering loggar den in på värden över SSH (qemu+ssh://, root som standard) för att köra virsh. Vem som helst som kan nå dess webbgränssnitt har i praktiken root på värden.

• Valfritt lösenordsskydd (Inställningar, Säkerhet): ange ett lösenord för att kräva inloggning, rensa det för att stänga av. Av som standard för användning i ett betrott LAN. Lösenordet lagras med Argon2id över ett värde pepprat med APP_KEY, så en kopierad /config är värdelös utan nyckeln och långsam att angripa med den. Ett nytt lösenord kräver minst 12 tecken; ett befintligt kortare fungerar tills det ändras. Sessioner är signerade (HMAC härledd ur APP_KEY) och en lösenordsändring ogiltigförklarar dem; inloggningar begränsas till fem misslyckanden per minut och klient.
• Tvåfaktorsautentisering (Inställningar): en tidskod från en autentiseringsapp utöver lösenordet, plus åtta engångsåterställningskoder som lämnas ut en gång när den slås på. Den delade hemligheten lagras krypterad med APP_KEY, och att stänga av den igen kräver en aktuell kod.
• Lösennycklar (WebAuthn) har ett eget kort när ett lösenord är angivet. De används tillsammans med lösenordet och aldrig i stället för det, så den som tar bort alla lösennycklar låser inte ute någon. De kräver ett riktigt domännamn och ett certifikat som webbläsaren litar på. Standardadressen https://<ip>:3443 är precis det som WebAuthn vägrar, och kortet säger det i stället för att erbjuda en knapp som misslyckas.
• Ändringar kräver JSON. En begäran som ändrar något måste skicka Content-Type: application/json och får inte vara markerad som cross-site av webbläsaren, så att en sida på en annan webbplats inte kan få din webbläsare att ändra inställningar på en LAN-adress. Ett skript som styr API:et skickar den headern; allt annat avvisas med 415.
• Eftersom spärren är opt-in är hela gränssnittet och API:et (inklusive off-site-uppsättningen, manipulationstest-rutterna och återställningskitet) nåbara av vem som helst som kan nå porten när den är osatt. Aktivera spärren när off-site, oföränderliga säkerhetskopior eller kryptering används.
• Kör BombVault endast på ett betrott, icke-exponerat nätverk. För fjärråtkomst, placera den bakom en reverse proxy som lägger till autentisering och TLS. Svar bär baslinje-säkerhetsrubriker (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Bakom en omvänd proxy bär varje begäran proxyns adress, så utan TRUSTED_PROXY räknar inloggningsbromsen alla klienter i samma hink och en angripares misslyckanden låser ute även dig. Ange proxyn i TRUSTED_PROXY för att få tillbaka räkning per klient.
• En omvänd proxy framför BombVault måste skicka vidare headern Authorization eller X-API-Key till /mcp och får inte buffra svaren, annars kan assistenter inte ansluta. Se MCP-server.
• MCP-slutpunkten /mcp svarar 404 tills en nyckel finns eller inloggning via OAuth är påslagen, och den kräver nyckel eller token av varje klient även när inloggningslösenordet är avstängt; ingen adress är undantagen, inte ens localhost. Den har inga verktyg för att återställa eller ta bort, och en återställning av en konfigurationssäkerhetskopia återkallar alla nycklar. Se MCP-server.
• Med HTTP_ONLY=true förlorar sessionscookien sin Secure-flagga (den måste det, för att fungera över vanlig HTTP), så aktivera bara lösenordet bakom en TLS-terminerande proxy om konfidentialitet är viktig.
• VM-säkerhetskopieringens SSH-anslutning litar på värdnyckeln vid första anslutningen (TOFU) och pinnar den därefter. Verifiera värdens nyckel out-of-band om din container-till-värd-väg inte är betrodd.
• Säkerhetskopior krypteras av restic när kryptering är aktiverad (Inställningar; på som standard), med nyckeln härledd från APP_KEY.

MCP-server

MCP-servern behöver ingen miljövariabel. Du slår på den genom att skapa en nyckel under Inställningar, Integrationer, MCP-server, och den svarar på /mcp på samma port som webbgränssnittet (till exempel https://192.168.1.10:3443/mcp). Utan en aktiv nyckel svarar den sökvägen med 404. Klienter, certifikat och gränser beskrivs på MCP-server.

VM-säkerhetskopiering över SSH

BombVault säkerhetskopierar KVM/libvirt-VM:ar utan att montera någon libvirt-sökväg. Den kör virsh på värden över SSH (qemu+ssh://), så den kan aldrig påverka din värds VM Manager.

Att montera värdens libvirt-socket i en container är bräckligt på Unraid: VM Manager äger de sökvägarna, och att slå om "Enable VMs" kan lämna libvirt i ett läge där den inte kan starta. SSH-nyckeln ger root på värden, samma förtroendenivå som Docker-socketen som BombVault redan använder.

Snabbuppsättning:

1. Inställningar, Integrationer, Värd-SSH: kopiera den visade publika nyckeln.
2. Lägg till den i Unraids /root/.ssh/authorized_keys (även bevarad till flashen så att den överlever omstarter).
3. Klicka på Testa anslutning.

Mallen lägger till --add-host=host.docker.internal:host-gateway så att containern kan nå värden. Sätt LIBVIRT_HOST till din Unraid-LAN-IP om det namnet inte löses upp (till exempel när containern körs på ett anpassat br0.x-nätverk). Om du ändrade Unraids SSH-port, sätt LIBVIRT_SSH_PORT att matcha. Live-ögonblicksbilder behöver dessutom qemu-gästagenten i VM:en och disken på /mnt/cache (inte /mnt/user).

Fullständig VM-uppsättnings- och nätverksguide

Den kompletta steg-för-steg-guiden (SSH-aktivering, beständig nyckelauktorisering, anpassat-nätverk- och VLAN-routning, metod per VM och felsökning på värdsidan) finns på docs/vm-backup-ssh-setup.md på GitHub.

Off-site-uppsättning

Sätt upp en off-site-replik på sidan Inställningar, Extern. Se Off-site och återställning för hela arbetsflödet (oföränderligt/append-only, manipulationstest och DR-övningar). I korthet:

• Backender: SMB/CIFS och NFS (montera resursen och peka en säkerhetskopiesökväg mot den), native restic-backender utan rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo), eller valfri rclone-fjärr (rclone:<remote>:<bucket>/path). Backblaze B2 har ingen inbyggd backend här: nå den via dess S3-slutpunkt (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), med nyckel-ID och programnyckel som S3-uppgifter.
• Delade molnautentiseringsuppgifter lagras krypterade under Inställningar, Molnåtkomst, Delade molnautentiseringsuppgifter.
• SSH-mål kräver inget installerat på den bortre sidan. sftp: behöver bara en SSH-server. Lägg till den publika nyckeln från Inställningar, Integrationer, Värd-SSH (även på /config/ssh/id_ed25519.pub) i målanvändarens ~/.ssh/authorized_keys.
• Off-site-kopia: BombVault replikerar nya ögonblicksbilder med restic copy på best-effort-basis, ovanpå ett (oftast lokalt) primärt repo. Varje domän har sitt eget off-site-schema, plus en Replikera nu-knapp.
• Flera off-site-mål per domän: varje domän kan replikera till flera off-site-mål samtidigt. Lägg till extra mål under Inställningar, Extern, var och en med sitt eget repository, S3-lagringsklass, append-only-flagga, retention och tillväxtbudget; de replikerar alla enligt den domänens off-site-schema. En befintlig enskild off-site-uppsättning förs över som det första målet.
• Mål: off-site-mål sätts upp en gång under Inställningar, Extern, Mål, med en guide som listar varje tjänst som stöds. Se Mål.
• Placering per objekt: varje container, VM och filuppsättning tänder Lokal och de mål som får dess säkerhetskopior. Inställningar, Lagring, Standardplaceringar anger detta per domän för objekt utan eget val. Se Placering per objekt.
• Retention per källa: både den lokala och off-site-policyn finns under Inställningar, Bevarande (lämna off-site-policyn helt-noll för att aldrig autotrimma off-site-ögonblicksbilder). Korten Lokal lagring och Extern lagring har var sitt Lagringsregler per källa, som ger containrar, VM:ar, flash, mappar, ZFS eller självbackupen egna lagringsregler, för deras lokala säkerhetskopior och för deras off-site-repo. En källa utan egna regler följer de gemensamma, och lagringen efter varje säkerhetskopia, off-site-kopian, en manuell rensning och förhandsvisningen av lagringen använder alla reglerna för källan de arbetar med. Ytterligare off-site-mål behåller reglerna som är inställda för dem under Inställningar, Extern.
• Bandbreddsgränser: begränsa restics uppladdnings-/nedladdningshastighet under Inställningar, Extern.
• Streaming först: under Inställningar, Extern väljer du mediaservrarna (Plex, Jellyfin och Emby är förvalda efter image-namnet), sändningstakten från vilken en server räknas som streamande, uppladdningsgränsen under streaming och hur länge efter en stream den vanliga gränsen kommer tillbaka.
• Kall och arkivlagringsklass (S3): för ett native S3-off-site-repo, välj en återställningsläsbar nivå (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). rclone-fjärrar ställer in sin klass i rclone-konfigurationen.
• Fjärrprimärt i stället för lokalt: en domäns säkerhetskopieringssökväg kan själv vara en av backenderna ovan, utan lokal kopia och utan replikeringssteg. Omkopplaren Lokal/Fjärran vid fältet och dess säkerhetsinställningar för bandbredd, append-only och tillväxtbudget beskrivs under Fjärranslutna primära arkiv.

Avvikelser

Avvikelsedetekteringen ställs in i kortet Avvikelser under Inställningar, Integritet. Varje kontroll sparas så fort du ändrar den, och de tre under reglaget döljs medan detekteringen är avstängd.

Inställning	Standard	Vad den gör
Upptäck avvikelser	På	Jämför varje säkerhetskopia med objektets egen historik. Avstängt kontrolleras inget nytt och posten Avvikelser försvinner ur sidofältet; kortet länkar fortfarande till tidigare fynd.
Känslighet	Balanserad	Strikt rapporterar mindre förändringar, Tillåtande bara stora.
Skicka avisering för	Bara kritiska fynd	Den lägsta allvarlighetsgrad som skickar ett meddelande via kanalerna som ställts in under Aviseringar. Upprepade misslyckade säkerhetskopior och dumpar och misslyckade schemalagda återställningskontroller skickar redan ett eget meddelande och skickas inte två gånger.
Behåll gamla säkerhetskopior när en källa krymper kraftigt eller skrivs om	På	Så länge ett objekt har ett öppet fynd för en nästan tom källa, en kraftig krympning eller det mesta av datan sparad på nytt låter gallring och rensning objektets gamla säkerhetskopior vara. Kvittera fyndet eller markera det som väntat för att släppa dem.

Varje objekt kan ha en egen känslighet och ett eget aviseringsminimum. Ställ in dem på sidan Avvikelser, där ett objekt med öppna fynd har dem under Övervakning på sitt kort och alla andra objekt öppnar dem från kortet Inget öppet, eller i objektets egen panel: mappavsnittet för en container och inställningarna för en VM (båda i avancerat läge), mappredigeraren för en mappuppsättning och sidorna Flash och Auto-säkerhetskopia. För ett ZFS-objekt finns de i objektets redigerare på sidan ZFS och gäller för varje datauppsättning i dess träd.

Portabla inställningar (exportera och importera)

Kortet Exportera / importera inställningar på sidan Inställningar, System skriver hela din BombVault-konfiguration (domäninställningar, off-site-mål, scheman, retention, aviseringar) till en portabel JSON-fil som du kan importera på en annan instans, så att en flytt till en ny box eller kloning av en uppsättning inte innebär att allt måste matas in på nytt för hand. Import visar en förhandsgranskning och ber om bekräftelse, och den rör aldrig dina säkerhetskopieringsdata eller historik.

Exporten kan innehålla uppgifter

Du väljer om off-site-, aviserings- och MQTT-broker-uppgifterna ska inkluderas i filen. Med uppgifter inkluderade är exporten lika känslig som ditt återställningskit, så förvara den på en säker plats. Utan dem innehåller filen endast icke-hemliga inställningar.