Konfiguráció

Ez az oldal a konténer környezeti változóit, a sablon által biztosított csatolásokat, a VM-mentést SSH-n keresztül, valamint a telephelyen kívüli beállítást ismerteti. A mentési tároló-útvonalak az alkalmazáson belül konfigurálhatók (Beállítások, Tárolás, Mentési útvonalak), nem környezeti változókon keresztül.

Környezeti változók

Változó	Kötelező	Leírás
APP_KEY	Igen	32 bájtos hexadecimális titok (64 hexadecimális karakter), amely a restic tároló jelszavának származtatására szolgál. Generáld az openssl rand -hex 32 paranccsal. Óvd ezt: az elvesztése visszaállíthatatlanná teszi a titkosított mentéseket.
LIBVIRT_HOST	VM-ekhez és ZFS-adatkészletekhez	Az SSH-n keresztül elért Unraid hoszt a VM-mentéshez (alapból host.docker.internal; a sablon egy LAN-IP helyőrzővel tölti ki előre). Használd az Unraid LAN IP-jét, egyéni br0.x hálózaton kötelező. A ZFS-adatkészletek mentése is ezt használja (sablonmező: Host SSH: Address); a 192.168.x.x helykitöltő nem beállítottnak számít.
LIBVIRT_SSH_PORT	Nem	A hoszt SSH-portja a VM-mentéshez (alapból 22). Sablonmező: Host SSH: Port, a ZFS-adatkészletekhez is.
LIBVIRT_SSH_USER	Nem	SSH-felhasználó a hoszton a VM-mentéshez (alapból root). Sablonmező: Host SSH: User, a ZFS-adatkészletekhez is.
LIBVIRT_URI	Nem	Teljes libvirt kapcsolati URI, amelyet a rendszer szó szerint használ a fenti három LIBVIRT_* változóból történő összeállítás helyett (ezeket a kapcsolati karakterlánc előállításakor ekkor figyelmen kívül hagyja). Alapból nincs beállítva. TrueNAS Scale-en szükséges, ahol a libvirtd egy nem szabványos socketen figyel, amit az összeállított forma nem tud kifejezni: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Lásd a docs/vm-backup-ssh-setup.md TrueNAS Scale szakaszát. Ha ez egy qemu+ssh:// URI, a LIBVIRT_HOST, LIBVIRT_SSH_USER és LIBVIRT_SSH_PORT közül mindegyik, amelyik nincs beállítva, ebből kerül átvételre, a BombVault saját SSH-parancsaihoz is (NVRAM-átvitel, ZFS-adatkészletek).
PORT	Nem	HTTP-port (alapból 3000; csak HTTP_ONLY=true mellett használatos).
HTTPS_PORT	Nem	HTTPS-port (alapból 3443; a sablon 1:1 arányban teszi közzé, így a WebUI a https://<ip>:3443 címen válaszol).
HTTP_ONLY	Nem	Állítsd true-ra az önaláírt HTTPS-figyelő letiltásához, és csak egyszerű HTTP kiszolgálásához (egy TLS-lezáró reverse proxy mögötti használatra).
BIND_HOST	Nem	A cím, amelyen a WebUI figyel (alapból 0.0.0.0, minden interfész). A konténerben hagyd beállítatlanul, mert a közzétett portjai minden interfészt igényelnek; a 127.0.0.1 a Dockeren kívüli futtatáshoz való. A healthcheck ugyanezt a címet kérdezi.
TRUSTED_PROXY	Nem	A BombVault előtt álló fordított proxy vesszővel elválasztott címei vagy CIDR-tartományai (például 192.168.20.11 vagy 10.0.0.0/8). Az X-Forwarded-For fejlécet csak ezekről az ugrásokról hisszük el, és a bejelentkezési fék ilyenkor valódi ügyfelenként számolja a hibákat, ahelyett hogy a proxy mögötti mindenkit egy vödörbe tenné. Beállítatlanul (alapértelmezés) senkinek sem hiszünk: a feltétel nélkül elhitt fejléc bárkinek megengedné, hogy saját vödröt válasszon.
HOST_SOURCE_ROOT	Nem	A Host Data-ként csatolt hoszt-útvonal (alapból /mnt). A BombVault a Docker által jelentett bind-mount forrásokat lefordítja az ez alatt a csatolás alatti útvonalakra. Csak akkor változtasd meg, ha eltérő hoszt-gyökeret csatoltál.
DATA_ROOT_SEGMENTS	Nem	Vesszővel elválasztott útvonal-szegmens nevek, amelyek egy bind-mount forrást mentési adatként jelölnek meg (alapból appdata, az Unraid /mnt/user/appdata/<container> konvenciójának megfelelően). Egy konténer bind-mountja automatikusan kiválasztódik mentésre, ha a felsorolt szegmensek közül BÁRMELYIK teljes útvonal-összetevőként megjelenik a hoszt-forrásában, például a DATA_ROOT_SEGMENTS=appdata,config a .../config csatolást is felveszi. A konténer adatmappájának megtalálására szolgáló további, mindig aktív módszerekért lásd: Mentési forrás felismerése.
PLATFORM	Nem	Kikényszeríti, hogy a BombVault milyen platformon fut szerinte, ahelyett hogy automatikusan felismerné: unraid, generic vagy truenas (alapból nincs beállítva: a flash csatolás alatti dockerMan jelző keresésével automatikusan felismeri az Unraidet, egyébként generic; egy nem felismert érték szintén generic-re esik vissza, naplózva). Állítsd be kifejezetten egy generikus Docker-hoszton vagy TrueNAS Scale-en, ahelyett hogy a csak Unraidre működő automatikus felismerésre hagyatkoznál; a generikus compose-fájl ezt teszi. Megváltoztatja az appdata-tartalék konvenciót, a példányok közötti visszaállítási cél alapértelmezéseit, valamint azt, hogy a csak Unraidre vonatkozó értesítési és kísérő bővítmény lépéseket egyáltalán megkísérli-e (lásd: internal/platform).
BOMBVAULT_SELF_CONTAINER	Nem	Magának a BombVault konténernek a neve, hogy soha ne mentse (és így ne állítsa le) önmagát.
BACKUP_MAX_HOURS	Nem	A maximális valós idejű órák száma, ameddig egyetlen mentési futás a tartományzárolását tarthatja, mielőtt kényszerítve megszakadna (egy védelem, hogy egy beragadt futás ne blokkolhassa örökre a tartományt). Üresen (az alapértelmezett) 48-at használ. Emeld nagyon nagy vagy lassú felhőmentésekhez (egy a korlátnál megszakított futás context deadline exceeded hibával hiúsul meg). Állítsd 0-ra a korlát teljes letiltásához.
BACKUP_STALL_HOURS	Nem	Órák, ameddig egy mentés egyáltalán nem haladhat, mielőtt megszakad. Üresen (az alapértelmezett) 2-t használ; állítsd 0-ra, hogy elakadás miatt soha ne szakadjon meg. Ez a két védelem közül a finomabb, és általában ez lép működésbe: azt figyeli, történik-e még valami, nem azt, mennyi ideje tart a futás, így egy lassú, de egészséges, több terabájtos mentést békén hagy, míg egy nem válaszoló megosztáson beragadt mentést napok helyett órák alatt leállít. 30 perc csend után, még mielőtt bármi megszakadna, figyelmeztetés kerül a naplóba. A bejárás haladásnak számít: a restic egy nagy fa bejárása közben egyetlen bájtot sem ír, és ezt a szakaszt a fájl- és bájtösszesítői alapján figyeli, nem a kiírt bájtok alapján. A két változó független egymástól, és a BACKUP_MAX_HOURS továbbra is korlátozza a tényleges mentés utáni szakaszokat (megőrzés, statisztikák, telephelyen kívüli másolat), ahol nincsenek figyelhető számlálók.
DB_DUMP_MAX_HOURS	Nem	Órák, ameddig egy automatikus adatbázis-dump futhat, mielőtt leállítják. Üresen (alapértelmezés) 6 órát jelent; a megengedett értékek 1-től 48-ig tartanak, és a korlát egy órával BACKUP_MAX_HOURS alatt marad (két óránál rövidebb érték esetén annak felénél), hogy egy hosszú dumpot a saját korlátja vágjon el és így is jelentsék, ahelyett hogy magával rántaná a mentést. Az a dump, amelyik nem halad tovább, már BACKUP_STALL_HOURS után leáll. A leállított dump önmagában lesz sikertelen, a konténer mentése pedig folytatódik. Unraidon a változót a BombVault konténerhez az Add another Path, Port, Variable ponttal veszed fel.
TZ	Nem	Időzóna az ütemezőhöz (például Europe/Berlin). Ha nincs beállítva, minden ütemezés UTC szerint fut: a 02:30-ra állított ütemezés ekkor 02:30 UTC-kor indul, nem a helyi idő szerint. Unraiden ezt soha nem kell beállítanod: a rendszer a saját időzónáját adja át minden konténernek. Az indítási napló megmondja, melyik zónát állapította meg. Egy nyári időszámítást használó zóna tavasszal kihagy egy futást, ősszel pedig egyet kétszer futtat, az UTC egyiket sem teszi, viszont évente kétszer egy órát elcsúszik az órádhoz képest.

Csatolások

Csatold a Docker socketet, a flasht (/boot) és a Host Data gyökeret (/mnt), ahogy a CA-sablonban látható. A mentési források és célok egyaránt a Host Data alatt találhatók, és az slave módban van csatolva, így egy távoli megosztás, amely a konténer indulása után csatolódik (például a /mnt/remotes alatt), újraindítás nélkül válik láthatóvá.

A ZFS-adatkészletek mentéséhez is ez a mód kell: egy adatkészlet pillanatképét a hoszt csak a konténer indulása után csatolja. Lásd: ZFS-adatkészletek.

A mentési tároló-útvonalak alapértelmezetten a /mnt/user/bombvault/{container,vms,flash,config,files,zfs} útvonalra mutatnak, és az első mentéskor jönnek létre. A helyet bármikor megváltoztathatod a Beállítások, Tárolás, Mentési útvonalak alatt. Minden útvonalmező mellett van egy beépített Helyi / Távoli kapcsoló is: egy útvonal helyi mappa helyett lehet távoli restic tároló is (s3:..., rest:..., sftp:..., rclone:...), ilyenkor a mentés közvetlenül oda megy, külön helyi másolat nélkül; lásd: Távoli elsődleges tárolók.

Hosztellenőrzés

A konténer elindulása után nyisd meg a /spike oldalt a webes felületen. Ez minden csatolást és CLI-t megvizsgál (Docker socket, libvirt, restic, qemu-img, rclone), és jelenti a hiányzó darabokat.

A mentési források felismerése

Minden konténernél a BombVault maga választja ki, mely bind csatolások és nevesített kötetek kerülnek mentésre. Egy útvonal akkor kerül be, ha az alábbiak bármelyike teljesül (az eredményt konténerenként bármikor felülírhatod a Mentett mappák alatt):

• Találat egy adatgyökér-szakaszra: a bind gazdagép oldali forrása a DATA_ROOT_SEGMENTS valamelyik szakaszát teljes útvonalelemként tartalmazza (alapértelmezés szerint csak appdata).
• A nevesített Docker-kötetek mindig bekerülnek, mert nincs eldobható megfelelőjük, így nincs mit kiszűrni, de csak akkor, ha a kötet valódi tárolási útvonala a gazdagépen maga is elérhető a Host Data csatoláson át, pontosan úgy, mint bármely más gazdagép-útvonal, amit a BombVault ment. A helyi kötetek alapértelmezett meghajtója a kötetet a démon saját adatgyökere alá teszi, vagyis a /var/lib/docker/volumes/<név>/_data helyre, hacsak nem módosítottad (ellenőrizd a docker info -f '{{.DockerRootDir}}' paranccsal). Ezt a helyet NEM fedi le az az egyetlen könyvtárból álló szűk Host Data csatolás, amit az általános docker-compose.yml alapból használ. Az elérhetetlen kötet csendben kimarad, ez nem hiba. Ahhoz, hogy általános gazdagépen a nevesített kötetek tényleg mentésre kerüljenek, irányítsd a Host Data csatolást (és a HOST_SOURCE_ROOT értéket) egy olyan közös szülőkönyvtárra, amely a Docker adatgyökerét is lefedi: a mérlegelést a compose fájl Host Data megjegyzése írja le (az Unraid ezt úgy kerüli meg, hogy ugyanezért az egész /mnt könyvtárat csatolja, a saját, legfelső szintű általános szokása szerint).
• Docker Compose projektkönyvtár: ha a konténeren ott a szokásos com.docker.compose.project.working_dir címke (a docker compose up automatikusan felteszi), az a könyvtár is bekerül, függetlenül attól, hogy bármelyik bind illeszkedett-e egy adatgyökér-szakaszra.
• Felülbírálás a bombvault.data címkével: tedd a konténerre a bombvault.data=true címkét, hogy MINDEN bind csatolása bekerüljön, olyan elrendezéshez, amit a fenti két szokás egyike sem fog meg (például egyetlen /srv/plex/config bind Compose projekt nélkül). Minden nem üres, false-tól különböző érték igaznak számít; hiányzó címke vagy bombvault.data=false semmit nem változtat.
• bombvault.dbdump címke: tedd a konténerre a bombvault.dbdump=false címkét, hogy kikapcsold az automatikus adatbázis-dumpját (0, no és off ugyanezt teszi), vagy nevezd meg a motort (postgres, mysql, mariadb), hogy olyan konténerről készüljön dump, amelyet a BombVault magától nem ismer fel. A címke erősebb a konténer kártyáján lévő kapcsolónál, ami Unraidon a megszokott út.

Biztonsági modell

Root-szintű vezérlés a hoszt felett

A Docker socketen keresztül a BombVault le tud állítani, el tud távolítani és újra létre tud hozni konténereket, valamint olvasni és írni tudja az appdatát, a VM-mentéshez pedig SSH-n keresztül bejelentkezik a hosztra (qemu+ssh://, alapból root), hogy futtassa a virsh parancsot. Aki eléri a webes felületét, annak gyakorlatilag root-jogosultsága van a hoszton.

• Opcionális jelszóvédelem (Beállítások, Biztonság): állíts be jelszót a bejelentkezés megköveteléséhez, töröld a kikapcsoláshoz. Alapértelmezés szerint kikapcsolva, megbízható LAN-on való használatra. A jelszót Argon2id tárolja egy APP_KEY-jel borsozott érték felett, így egy lemásolt /config a kulcs nélkül semmit sem ér, a kulccsal pedig lassan törhető. Az új jelszónak legalább 12 karakter kell legyen; egy meglévő rövidebb addig működik, amíg meg nem változtatod. A munkamenetek aláírtak (az APP_KEY-ből származó HMAC), és a jelszó módosítása érvényteleníti őket; a bejelentkezések ügyfelenként percenként öt hibára korlátozottak.
• Kétlépcsős azonosítás (Beállítások): időalapú kód egy hitelesítő alkalmazásból a jelszó mellé, továbbá nyolc egyszer használatos helyreállítási kód, amelyeket a bekapcsoláskor egyszer adunk ki. A közös titkot APP_KEY-jel titkosítva tároljuk, a kikapcsoláshoz pedig aktuális kód kell.
• Hozzáférési kulcsok (WebAuthn): saját kártyán jelennek meg, amint van beállított jelszó, a jelszó mellett és soha nem helyette, így az összes hozzáférési kulcs eltávolítása senkit sem zár ki. Valódi domainnév és a böngésző által megbízhatónak tartott tanúsítvány kell hozzájuk. Az alapértelmezett https://<ip>:3443 pontosan az, amit a WebAuthn elutasít, és a kártya ezt meg is mondja, ahelyett hogy egy kudarcra ítélt gombot kínálna.
• A módosításokhoz JSON kell. Egy kérésnek, amely módosít valamit, Content-Type: application/json fejlécet kell küldenie, és a böngésző nem jelölheti cross-site kérésnek, így egy másik webhely oldala nem veheti rá a böngésződet, hogy egy LAN-címen beállításokat módosítson. Az API-t vezérlő szkript küldi ezt a fejlécet; minden mást 415 kóddal elutasít.
• Mivel a védelem opcionális, ha nincs beállítva, a teljes felület és API (beleértve a telephelyen kívüli beállítást, a manipulációs teszt útvonalait és a helyreállítási csomagot) elérhető bárki számára, aki eléri a portot. Kapcsold be a védelmet, amint telephelyen kívüli, módosíthatatlan mentések vagy titkosítás van használatban.
• A BombVaultot csak megbízható, nem kitett hálózaton futtasd. A távoli hozzáféréshez tedd egy reverse proxy mögé, amely hitelesítést és TLS-t ad hozzá. A válaszok alapszintű biztonsági fejléceket hordoznak (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Fordított proxy mögött minden kérés a proxy címét viseli, így TRUSTED_PROXY nélkül a fék minden ügyfelet egy vödörben számol, és egy támadó hibái téged is kizárnak. Add meg a proxyt a TRUSTED_PROXY értékeként, hogy visszatérjen az ügyfelenkénti számolás.
• A BombVault előtti fordított proxynak tovább kell adnia az Authorization vagy az X-API-Key fejlécet a /mcp felé, és nem pufferelheti a válaszokat, különben az asszisztensek nem tudnak csatlakozni. Lásd MCP-kiszolgáló.
• Az MCP-végpont (/mcp) 404-et ad, amíg nincs kulcs, vagy amíg nincs bekapcsolva az OAuth-bejelentkezés, és minden klienstől elkéri a kulcsát vagy tokenjét akkor is, ha a bejelentkezési jelszó ki van kapcsolva; egyetlen cím sem kivétel, a localhost sem. Nincsenek visszaállító vagy törlő eszközei, és egy konfigurációs mentés visszaállítása minden kulcsot visszavon. Lásd MCP-kiszolgáló.
• A HTTP_ONLY=true mellett a munkamenet-süti elveszíti a Secure jelzőjét (muszáj, hogy egyszerű HTTP-n működjön), így csak egy TLS-lezáró proxy mögött kapcsold be a jelszót, ha a bizalmasság számít.
• A VM-mentés SSH-kapcsolata az első kapcsolatfelvételkor megbízik a hoszt-kulcsban (TOFU), és utána rögzíti. Ellenőrizd a hoszt kulcsát sávon kívül, ha a konténer-hoszt útvonalad nem megbízható.
• A mentések a restic által titkosítottak, ha a titkosítás engedélyezve van (Beállítások; alapból be), a kulcs az APP_KEY-ből származtatva.

MCP-kiszolgáló

Az MCP-kiszolgálóhoz nem kell környezeti változó. Úgy kapcsolod be, hogy létrehozol egy kulcsot a Beállítások, Integrációk, MCP-kiszolgáló részen, és a /mcp útvonalon válaszol ugyanazon a porton, mint a webes felület (például https://192.168.1.10:3443/mcp). Aktív kulcs nélkül ez az útvonal 404-gyel válaszol. A klienseket, a tanúsítványokat és a korlátokat az MCP-kiszolgáló oldal írja le.

VM-mentés SSH-n keresztül

A BombVault a KVM/libvirt VM-eket bármely libvirt-útvonal csatolása nélkül menti. A virsh parancsot a hoszton, SSH-n keresztül futtatja (qemu+ssh://), így soha nem tudja befolyásolni a hoszt VM Managerét.

A hoszt libvirt-socketjének csatolása egy konténerbe Unraiden törékeny megoldás: ezeket az útvonalakat a VM Manager kezeli, és az "Enable VMs" átkapcsolása után előfordulhat, hogy a libvirt nem tud elindulni. Az SSH-kulcs root-jogot ad a hoszton, vagyis ugyanakkora bizalmat, mint a Docker socket, amelyet a BombVault már most is használ.

Gyors beállítás:

1. Beállítások, Integrációk, Gazdagép SSH: másold ki a megjelenített nyilvános kulcsot.
2. Fűzd hozzá az Unraid /root/.ssh/authorized_keys fájljához (a flashre is mentve, így túléli az újraindításokat).
3. Kattints a Kapcsolat tesztelése gombra.

A sablon hozzáadja a --add-host=host.docker.internal:host-gateway opciót, hogy a konténer elérhesse a hosztot. Állítsd a LIBVIRT_HOST-ot az Unraid LAN IP-jére, ha ez a név nem oldódik fel (például amikor a konténer egyéni br0.x hálózaton fut). Ha megváltoztattad az Unraid SSH-portját, állítsd be a LIBVIRT_SSH_PORT-ot, hogy egyezzen. Az élő pillanatképekhez ezen felül szükség van a qemu guest agentre a VM-ben, és arra, hogy a lemez a /mnt/cache-en (ne a /mnt/user-en) legyen.

Teljes VM-beállítási és hálózati útmutató

A teljes, lépésről lépésre útmutató (SSH engedélyezése, tartós kulcs-engedélyezés, egyéni hálózati és VLAN-útválasztás, VM-enkénti módszer és hoszt-oldali hibaelhárítás) a docs/vm-backup-ssh-setup.md oldalon található a GitHubon.

Telephelyen kívüli beállítás

Állíts be egy telephelyen kívüli replikát a Beállítások, Telephelyen kívüli oldalon. A teljes munkafolyamathoz (módosíthatatlan/append-only, manipulációs tesztelés és DR-próbák) lásd: Telephelyen kívüli mentés és helyreállítás. Röviden:

• Backendek: SMB/CIFS és NFS (csatold a megosztást, és irányíts rá egy Mentési útvonalat), natív restic backendek rclone nélkül (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo), vagy bármely rclone remote (rclone:<remote>:<bucket>/path). A Backblaze B2-nek itt nincs saját backendje: az S3-végpontján keresztül érhető el (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), a kulcsazonosítóval és az alkalmazáskulccsal mint S3-hitelesítő adatokkal.
• A megosztott felhőbeli hitelesítő adatok titkosítva tárolódnak a Beállítások, Felhőhozzáférés, Megosztott felhőbeli hitelesítő adatok alatt.
• Az SSH-célokhoz semmit sem kell telepíteni a túloldalon. Az sftp: csak egy SSH-szervert igényel. Add hozzá a nyilvános kulcsot a Beállítások, Integrációk, Gazdagép SSH alól (a /config/ssh/id_ed25519.pub alatt is) a célfelhasználó ~/.ssh/authorized_keys fájljához.
• Telephelyen kívüli másolat: A BombVault az új pillanatképeket restic copy segítségével, legjobb szándék szerint replikálja, egy (általában helyi) elsődleges tároló mellé. Minden tartománynak saját telephelyen kívüli ütemezése van, plusz egy Replikálás most gomb.
• Több telephelyen kívüli cél tartományonként: minden tartomány egyszerre több telephelyen kívüli célra is replikálhat. Adj hozzá további célokat a Beállítások, Telephelyen kívüli alatt, mindegyiket saját tárolóval, S3-tárolási osztállyal, append-only jelzővel, megőrzéssel és növekedési kerettel; mindegyik az adott tartomány telephelyen kívüli ütemezése szerint replikál. Egy meglévő egyetlen telephelyen kívüli beállítás az első célként öröklődik át.
• Célok: a telephelyen kívüli célokat egyszer kell beállítani a Beállítások, Telephelyen kívüli, Célok alatt, egy varázslóval, amely felsorol minden támogatott szolgáltatást. Lásd: Célok.
• Elhelyezés elemenként: minden konténer, VM és mappakészlet világítja be a Helyit és azokat a célokat, amelyek megkapják a mentéseit. A Beállítások, Tárolás, Elhelyezési alapértelmezések ezt tartományonként határozza meg a saját választás nélküli elemekre. Lásd: Elhelyezés elemenként.
• Megőrzés forrásonként: a helyi és a telephelyen kívüli szabály egyaránt a Beállítások, Megőrzés alatt él (hagyd a telephelyen kívülit nullán, hogy soha ne nyesse automatikusan a telephelyen kívüli pillanatképeket). A Helyi megőrzés és a Telephelyen kívüli megőrzés kártyán egyaránt ott van a Megőrzési szabályok forrásonként, amely saját megőrzési szabályokat ad a konténereknek, VM-eknek, a flash-nek, a mappáknak, a ZFS-nek vagy az önmentésnek, a helyi mentéseikhez és a telephelyen kívüli repójukhoz. A saját szabályok nélküli forrás a közöseket követi, a mentés utáni megőrzés, a telephelyen kívüli másolás, a kézi tisztítás és a megőrzési előnézet pedig mind az adott forrás szabályait használja. A további telephelyen kívüli célok a Beállítások, Telephelyen kívüli alatt nekik beállított szabályokat követik.
• Sávszélesség-korlátok: korlátozd a restic fel- és letöltési sebességét a Beállítások, Telephelyen kívüli alatt.
• Elsőbbség a streamelésnek: a Beállítások, Telephelyen kívüli alatt választod ki a médiaszervereket (a Plex, Jellyfin és Emby a képnév alapján előre ki van jelölve), azt a küldési sebességet, amelytől egy szerver streamelőnek számít, a streamelés alatti feltöltési korlátot, és hogy egy stream után mennyi idővel tér vissza a szokásos korlát.
• Hideg és archív tárolási osztály (S3): egy natív S3 telephelyen kívüli tárolóhoz válassz egy visszaállításra olvasható szintet (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). Az rclone remote-ok a saját osztályukat az rclone konfigban állítják be.
• Távoli elsődleges tároló helyi helyett: egy tartomány Mentési útvonala maga is lehet a fenti backendek egyike, helyi másolat és replikációs lépés nélkül. A beépített Helyi/Távoli kapcsolót és a biztonsági beállításait (sávszélesség, append-only, növekedési keret) a Távoli elsődleges tárolók szakasz írja le.

Anomáliák

Az anomáliák észlelését a Beállítások, Integritás alatti Anomáliák kártyán állítod be. Minden vezérlő azonnal ment, amint módosítod, a kapcsoló alatti három pedig rejtve marad, amíg az észlelés ki van kapcsolva.

Beállítás	Alapérték	Mit csinál
Anomáliák felismerése	Be	Minden mentést összevet az elem saját előzményeivel. Kikapcsolva semmi újat nem ellenőriz, és az Anomáliák bejegyzés eltűnik az oldalsávból; a kártya továbbra is a korábbi észlelésekre mutat.
Érzékenység	Kiegyensúlyozott	A Szigorú kisebb változásokat is jelez, a Megengedő csak nagyokat.
Értesítés küldése ekkor	Csak kritikus leletek	Az a legalacsonyabb súlyosság, amely üzenetet küld az Értesítések alatt beállított csatornákon. Az ismételten sikertelen mentések és dumpok, valamint a sikertelen ütemezett visszaállítási ellenőrzések már saját üzenetet küldenek, ezeket nem küldi el kétszer.
Régi mentések megtartása, ha egy forrás erősen zsugorodik vagy újraíródik	Be	Amíg egy elemnek nyitott észlelése van majdnem üres forrás, erős zsugorodás vagy az adatok nagy részének újbóli eltárolása miatt, a megőrzés és a tisztítás békén hagyja a régi mentéseit. Nyugtázd az észlelést vagy jelöld várhatónak, hogy felszabaduljanak.

Minden elemnek lehet saját érzékenysége és saját értesítési minimuma. Ezeket az Anomáliák oldalon állítod be, ahol a nyitott megállapítással rendelkező elemnél a kártyáján a Figyelés alatt vannak, minden más elemnél pedig a Nincs nyitott kártyáról nyílnak meg, vagy az elem saját paneljén: egy konténer mappaszakaszában és egy virtuális gép beállításaiban (mindkettő speciális módban), egy mappakészlet mappaszerkesztőjében, valamint a Flash és a Önmentés oldalon. Egy ZFS-elemnél ezek az elem szerkesztőjében vannak a ZFS oldalon, és a fa minden adatkészletére érvényesek.

Hordozható beállítások (exportálás és importálás)

Az Beállítások exportálása / importálása kártya a Beállítások, Rendszer oldalon a teljes BombVault-konfigurációdat (tartománybeállítások, telephelyen kívüli célok, ütemezések, megőrzés, értesítések) egy hordozható JSON-fájlba írja, amelyet egy másik példányon importálhatsz, így egy új gépre költözés vagy egy beállítás klónozása nem jelenti azt, hogy mindent kézzel kell újra beírni. Az importálás előnézetet mutat és megerősítést kér, és soha nem érinti a mentési adataidat vagy előzményeidet.

Az export hitelesítő adatokat tartalmazhat

Te választod meg, hogy belefoglalod-e a telephelyen kívüli, értesítési és MQTT-bróker hitelesítő adatokat a fájlba. A hitelesítő adatokkal együtt az export olyan érzékeny, mint a helyreállítási csomagod, ezért tárold biztonságos helyen. Nélkülük a fájl csak nem-titkos beállításokat tartalmaz.