Konfiguracja

Ta strona omawia zmienne środowiskowe kontenera, montaże udostępniane przez szablon, kopię VM przez SSH oraz konfigurację poza siedzibą. Ścieżki repozytoriów kopii są konfigurowane wewnątrz aplikacji (Ustawienia, Pamięć, Ścieżki kopii), a nie przez zmienne środowiskowe.

Zmienne środowiskowe

Zmienna	Wymagana	Opis
APP_KEY	Tak	32-bajtowy sekret hex (64 znaki hex) używany do wyprowadzenia hasła repozytorium restic. Wygeneruj poleceniem openssl rand -hex 32. Chroń go: jego utrata sprawia, że zaszyfrowane kopie zapasowe stają się nieodzyskiwalne.
LIBVIRT_HOST	Dla VM i zbiorów danych ZFS	Host Unraid osiągany przez SSH do kopii VM (domyślnie host.docker.internal; szablon wstępnie wypełnia zastępczy adres IP w LAN). Użyj swojego IP Unraid w LAN, wymagane w niestandardowej sieci br0.x. Używane też przez kopie zbiorów danych ZFS (pole szablonu Host SSH: Address); symbol zastępczy 192.168.x.x liczy się jako nieustawiony.
LIBVIRT_SSH_PORT	Nie	Port SSH hosta do kopii VM (domyślnie 22). Pole szablonu Host SSH: Port, także dla zbiorów danych ZFS.
LIBVIRT_SSH_USER	Nie	Użytkownik SSH na hoście do kopii VM (domyślnie root). Pole szablonu Host SSH: User, także dla zbiorów danych ZFS.
LIBVIRT_URI	Nie	Pełny URI połączenia libvirt, używany dosłownie zamiast budowania go z trzech powyższych zmiennych LIBVIRT_* (które są wtedy ignorowane przy tworzeniu ciągu połączenia). Domyślnie brak. Wymagany na TrueNAS Scale, którego libvirtd nasłuchuje na niestandardowym gnieździe, którego nie da się wyrazić w formie budowanego ciągu: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Zobacz sekcję TrueNAS Scale w docs/vm-backup-ssh-setup.md. Jeśli to URI qemu+ssh://, każda z LIBVIRT_HOST, LIBVIRT_SSH_USER i LIBVIRT_SSH_PORT, która nie jest ustawiona, jest z niego brana, także dla własnych poleceń SSH BombVault (przesyłanie NVRAM, zbiory danych ZFS).
PORT	Nie	Port HTTP (domyślnie 3000; używany tylko z HTTP_ONLY=true).
HTTPS_PORT	Nie	Port HTTPS (domyślnie 3443; szablon publikuje go 1:1, więc WebUI odpowiada pod https://<ip>:3443).
HTTP_ONLY	Nie	Ustaw true, aby wyłączyć samopodpisany nasłuch HTTPS i serwować wyłącznie zwykły HTTP (do użytku za odwrotnym proxy terminującym TLS).
BIND_HOST	Nie	Adres, na którym nasłuchuje WebUI (domyślnie 0.0.0.0, wszystkie interfejsy). W kontenerze zostaw go nieustawionego, bo opublikowane porty potrzebują wszystkich interfejsów; 127.0.0.1 pasuje do uruchomienia poza Dockerem. Healthcheck odpytuje ten sam adres.
TRUSTED_PROXY	Nie	Rozdzielone przecinkami adresy lub zakresy CIDR odwrotnego proxy stojącego przed BombVaultem (na przykład 192.168.20.11 albo 10.0.0.0/8). Tylko z tych węzłów nagłówek X-Forwarded-For jest brany na wiarę, a ogranicznik logowań liczy wtedy nieudane próby na rzeczywistego klienta, zamiast wrzucać wszystkich za proxy do jednego worka. Nieustawione (domyślnie) oznacza: nie ufaj nikomu. Nagłówek brany na wiarę bezwarunkowo pozwoliłby każdemu wybrać sobie własny licznik.
HOST_SOURCE_ROOT	Nie	Ścieżka hosta zamontowana jako Host Data (domyślnie /mnt). BombVault tłumaczy źródła montaży bind zgłaszane przez Docker na ścieżki pod tym montażem. Zmieniaj tylko, jeśli zamontowałeś inny katalog główny hosta.
DATA_ROOT_SEGMENTS	Nie	Lista nazw segmentów ścieżki oddzielonych przecinkami, które oznaczają źródło montażu bind jako dane kopii zapasowej (domyślnie appdata, zgodnie z konwencją Unraid /mnt/user/appdata/<container>). Montaż bind kontenera jest automatycznie wybierany do kopii, gdy KTÓRYKOLWIEK z wymienionych segmentów pojawia się jako pełny segment ścieżki jego źródła na hoście; na przykład DATA_ROOT_SEGMENTS=appdata,config obejmuje też montaż .../config. Zobacz Wykrywanie źródeł kopii, aby poznać inne, zawsze aktywne sposoby znajdowania folderu danych kontenera.
PLATFORM	Nie	Wymusza platformę, na której BombVault uznaje, że działa, zamiast wykrywać ją automatycznie: unraid, generic lub truenas (domyślnie brak: automatycznie wykrywa Unraid, sondując obecność jego znacznika dockerMan pod montowaniem flash, w przeciwnym razie generic; nierozpoznana wartość również powoduje użycie generic, co jest logowane). Ustaw ją jawnie na zwykłym hoście Docker lub TrueNAS Scale, zamiast polegać na automatycznym sondowaniu dostępnym tylko na Unraid. Plik compose dla zwykłego hosta robi to za Ciebie. Zmienia zastępczą konwencję appdata, domyślne miejsca docelowe przywracania między instancjami oraz to, czy w ogóle podejmowane są kroki powiadomień i pluginu towarzyszącego dostępne tylko na Unraid (zobacz internal/platform).
BOMBVAULT_SELF_CONTAINER	Nie	Nazwa samego kontenera BombVault, aby nigdy nie tworzył kopii (a więc nie zatrzymywał) samego siebie.
BACKUP_MAX_HOURS	Nie	Maksymalna liczba godzin rzeczywistego czasu, przez które pojedyncze uruchomienie kopii może trzymać blokadę swojej domeny, zanim zostanie wymuszenie anulowane (zabezpieczenie, aby zaklinowane uruchomienie nie mogło zablokować domeny na zawsze). Puste (domyślnie) używa 48. Zwiększ dla bardzo dużych lub powolnych kopii w chmurze (uruchomienie anulowane na limicie kończy się błędem context deadline exceeded). Ustaw 0, aby całkowicie wyłączyć limit.
BACKUP_STALL_HOURS	Nie	Godziny, przez które kopia może nie robić żadnego postępu, zanim zostanie anulowana. Puste (domyślnie) oznacza 2; ustaw 0, aby nigdy nie anulować z powodu zastoju. To dokładniejsze z dwóch zabezpieczeń i zwykle to ono zadziała: pilnuje, czy coś się jeszcze dzieje, a nie tego, jak długo trwa uruchomienie, więc powolna, ale zdrowa kopia wielu terabajtów zostaje w spokoju, a kopia zaklinowana na nieodpowiadającym udziale jest zatrzymywana po godzinach, a nie po dniach. Po 30 minutach ciszy, zanim cokolwiek zostanie anulowane, zapisywane jest ostrzeżenie w logu. Skanowanie liczy się jako postęp: restic nie zapisuje żadnych bajtów, gdy przechodzi duże drzewo, i ta faza jest pilnowana przez jego sumy plików i bajtów, a nie przez zapisane bajty. Obie zmienne są niezależne, a BACKUP_MAX_HOURS nadal ogranicza fazy po samej kopii (przechowywanie, statystyki, kopia poza siedzibą), w których nie ma liczników do obserwowania.
DB_DUMP_MAX_HOURS	Nie	Godziny, przez które jeden automatyczny zrzut bazy danych może trwać, zanim zostanie zatrzymany. Puste (domyślnie) oznacza 6; dozwolone są wartości od 1 do 48, a limit zostaje godzinę poniżej BACKUP_MAX_HOURS (na połowie tej wartości, gdy jest krótsza niż dwie godziny), żeby długi zrzut został ucięty własnym limitem i tak zgłoszony, zamiast pociągnąć kopię za sobą. Zrzut, który przestaje robić postępy, zatrzymywany jest wcześniej, po BACKUP_STALL_HOURS. Zatrzymany zrzut kończy się niepowodzeniem sam z siebie, a kopia kontenera trwa dalej. Na Unraidzie dodaj zmienną do kontenera BombVault przez Add another Path, Port, Variable.
TZ	Nie	Strefa czasowa dla harmonogramu (na przykład Europe/Berlin). Jeśli nie zostanie ustawiona, wszystkie harmonogramy działają w UTC: harmonogram ustawiony na 02:30 uruchomi się wtedy o 02:30 UTC, a nie według czasu lokalnego. W Unraid nigdy nie ustawiasz tego samodzielnie: system przekazuje własną strefę czasową do każdego kontenera. Dziennik startowy podaje, jaką strefę ostatecznie przyjęto. Strefa z czasem letnim wiosną pomija jedno uruchomienie, a jesienią wykonuje jedno dwa razy, natomiast UTC nie robi żadnej z tych rzeczy, za to dwa razy w roku przesuwa się o godzinę względem Twojego zegara.

Montaże

Zamontuj gniazdo Docker, flash (/boot) oraz katalog główny Host Data (/mnt), jak pokazano w szablonie CA. Zarówno źródła, jak i cele kopii zapasowych znajdują się pod Host Data i jest on montowany jako slave, więc zdalny udział, który montuje się po uruchomieniu kontenera (na przykład pod /mnt/remotes), staje się widoczny bez restartu.

Kopie zbiorów danych ZFS też potrzebują tego trybu: host montuje migawkę zbioru dopiero po starcie kontenera. Zobacz Zbiory danych ZFS.

Ścieżki repozytoriów kopii domyślnie wynoszą /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, tworzone przy pierwszej kopii. Zmień lokalizację w dowolnym momencie w Ustawienia, Pamięć, Ścieżki kopii. Każde pole ścieżki ma też wbudowany przełącznik Lokalne / Zdalne: ścieżka może być zdalnym repozytorium restic (s3:..., rest:..., sftp:..., rclone:...) zamiast lokalnego folderu, a kopia trafia wtedy prosto tam, bez osobnej kopii lokalnej; zobacz Zdalne repozytoria podstawowe.

Sprawdzenie integracji z hostem

Otwórz /spike w interfejsie webowym po uruchomieniu kontenera. Sonduje ono każdy montaż i każde CLI (gniazdo Docker, libvirt, restic, qemu-img, rclone) i zgłasza wszelkie brakujące elementy.

Wykrywanie źródeł kopii zapasowej

Dla każdego kontenera BombVault sam wybiera, które montowania bind i wolumeny nazwane trafiają do kopii. Ścieżka zostaje przyjęta, gdy zachodzi którykolwiek z poniższych warunków (wynik zawsze można nadpisać dla danego kontenera w jego sekcji Foldery do kopii):

• Trafienie na segment katalogu danych: źródło bindu na hoście zawiera jeden z segmentów DATA_ROOT_SEGMENTS jako pełny człon ścieżki (domyślnie tylko appdata).
• Nazwane wolumeny Dockera są dołączane zawsze, bo nie mają jednorazowego odpowiednika, więc nie ma czego filtrować, ale tylko wtedy, gdy rzeczywista ścieżka wolumenu na hoście jest osiągalna przez montowanie Host Data, dokładnie tak jak każda inna ścieżka hosta, którą BombVault archiwizuje. Domyślny sterownik wolumenów lokalnych umieszcza wolumen pod katalogiem danych samego demona, czyli /var/lib/docker/volumes/<nazwa>/_data, o ile nie zostało to zmienione (sprawdź poleceniem docker info -f '{{.DockerRootDir}}'). To miejsce NIE jest objęte wąskim, jednokatalogowym montowaniem Host Data, którego domyślnie używa ogólny docker-compose.yml. Nieosiągalny wolumen jest po cichu pomijany, to nie jest błąd. Aby naprawdę archiwizować nazwane wolumeny na zwykłym hoście, skieruj Host Data (oraz HOST_SOURCE_ROOT) na wspólny katalog nadrzędny obejmujący także katalog danych Dockera: kompromis opisuje komentarz Host Data w pliku compose (Unraid omija to, montując z tego samego powodu całe /mnt, własną uniwersalną konwencję najwyższego poziomu).
• Katalog projektu Docker Compose: jeśli kontener nosi standardową etykietę com.docker.compose.project.working_dir (ustawianą automatycznie przez docker compose up), ten katalog również zostaje dodany, niezależnie od tego, czy któryś bind pasował do segmentu katalogu danych.
• Nadpisanie etykietą bombvault.data: ustaw na kontenerze etykietę bombvault.data=true, aby objąć WSZYSTKIE jego montowania bind, dla układu, którego nie łapie żadna z powyższych konwencji (na przykład pojedynczy bind /srv/plex/config bez projektu Compose). Każda niepusta wartość inna niż false liczy się jako prawda; brak etykiety lub bombvault.data=false niczego nie zmienia.
• Etykieta bombvault.dbdump: ustaw na kontenerze bombvault.dbdump=false, aby wyłączyć jego automatyczny zrzut bazy danych (0, no i off działają tak samo), albo podaj silnik (postgres, mysql, mariadb), aby zrzucać kontener, którego BombVault sam nie rozpoznaje. Etykieta bierze górę nad przełącznikiem na karcie kontenera, który na Unraidzie jest zwykłą drogą.

Model bezpieczeństwa

Kontrola nad hostem równoważna uprawnieniom root

Poprzez gniazdo Docker BombVault może zatrzymywać, usuwać i odtwarzać kontenery oraz odczytywać i zapisywać appdata, a w celu tworzenia kopii VM loguje się do hosta przez SSH (qemu+ssh://, domyślnie root), aby uruchomić virsh. Każdy, kto może dotrzeć do jego interfejsu webowego, ma faktycznie uprawnienia root na hoście.

• Opcjonalna ochrona hasłem (Ustawienia, Bezpieczeństwo): ustaw hasło, aby wymagać logowania, wyczyść je, aby wyłączyć. Domyślnie wyłączone, do użytku w zaufanej sieci LAN. Hasło jest zapisywane algorytmem Argon2id na wartości popieprzonej kluczem APP_KEY, więc skopiowany /config bez klucza nic nie da, a z kluczem atak jest powolny. Nowe hasło musi mieć co najmniej 12 znaków; istniejące krótsze działa dalej, dopóki go nie zmienisz. Sesje są podpisane (HMAC wyprowadzony z APP_KEY), a zmiana hasła je unieważnia; logowania są ograniczone do pięciu nieudanych prób na minutę na klienta.
• Uwierzytelnianie dwuskładnikowe (Ustawienia): kod czasowy z aplikacji uwierzytelniającej oprócz hasła oraz osiem jednorazowych kodów zapasowych wydawanych raz przy włączeniu. Wspólny sekret jest przechowywany zaszyfrowany kluczem APP_KEY, a wyłączenie wymaga aktualnego kodu.
• Klucze dostępu (WebAuthn) mają własną kartę, gdy tylko ustawione jest hasło, i działają obok hasła, nigdy zamiast niego, więc usunięcie wszystkich kluczy dostępu nikogo nie zablokuje. Wymagają prawdziwej nazwy domeny i certyfikatu, któremu przeglądarka ufa. Domyślny https://<ip>:3443 to dokładnie to, co WebAuthn odrzuca, i karta to mówi, zamiast oferować przycisk, który zawiedzie.
• Zmiany wymagają JSON. Żądanie, które coś zmienia, musi wysyłać Content-Type: application/json i nie może być oznaczone przez przeglądarkę jako cross-site, więc strona w innej witrynie nie może zmusić Twojej przeglądarki do zmiany ustawień pod adresem w LAN. Skrypt, który steruje API, wysyła ten nagłówek; wszystko inne jest odrzucane z kodem 415.
• Ponieważ brama jest opcjonalna, gdy nie jest ustawiona, cały interfejs i API (w tym konfiguracja poza siedzibą, trasy tamper testu oraz zestaw odzyskiwania) są osiągalne dla każdego, kto może dotrzeć do portu. Włącz bramę, gdy tylko używasz kopii poza siedzibą, kopii niezmiennych lub szyfrowania.
• Uruchamiaj BombVault wyłącznie w zaufanej, nieudostępnianej na zewnątrz sieci. Do zdalnego dostępu umieść go za odwrotnym proxy dodającym uwierzytelnianie i TLS. Odpowiedzi niosą podstawowe nagłówki bezpieczeństwa (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Za odwrotnym proxy każde żądanie niesie adres proxy, więc bez TRUSTED_PROXY ogranicznik liczy wszystkich klientów razem, a nieudane próby atakującego blokują także ciebie. Wskaż proxy w TRUSTED_PROXY, aby wrócić do liczenia na klienta.
• Reverse proxy przed BombVault musi przekazywać nagłówek Authorization albo X-API-Key do /mcp i nie może buforować odpowiedzi, inaczej asystenci się nie połączą. Zobacz Serwer MCP.
• Punkt końcowy MCP /mcp odpowiada 404, dopóki nie istnieje klucz albo nie włączono logowania przez OAuth, i żąda od każdego klienta jego klucza lub tokenu nawet przy wyłączonym haśle logowania; żaden adres nie jest wyjątkiem, nawet localhost. Nie ma narzędzi do przywracania ani usuwania, a przywrócenie kopii konfiguracji unieważnia wszystkie klucze. Zobacz Serwer MCP.
• Przy HTTP_ONLY=true ciasteczko sesji traci flagę Secure (musi, aby działać po zwykłym HTTP), więc włączaj hasło za proxy terminującym TLS tylko, jeśli poufność ma znaczenie.
• Połączenie SSH do kopii VM ufa kluczowi hosta przy pierwszym połączeniu (TOFU) i przypina go potem. Zweryfikuj klucz hosta poza pasmem, jeśli ścieżka od kontenera do hosta nie jest zaufana.
• Kopie zapasowe są szyfrowane przez restic, gdy szyfrowanie jest włączone (Ustawienia; domyślnie włączone), z kluczem wyprowadzonym z APP_KEY.

Serwer MCP

Serwer MCP nie potrzebuje żadnej zmiennej środowiskowej. Włączasz go, tworząc klucz w Ustawienia, Integracje, Serwer MCP, a odpowiada pod /mcp na tym samym porcie co interfejs WWW (na przykład https://192.168.1.10:3443/mcp). Bez aktywnego klucza ta ścieżka odpowiada 404. Klientów, certyfikaty i limity opisuje strona Serwer MCP.

Kopia VM przez SSH

BombVault tworzy kopie maszyn wirtualnych KVM/libvirt bez montowania jakiejkolwiek ścieżki libvirt. Uruchamia virsh na hoście przez SSH (qemu+ssh://), więc nigdy nie może wpłynąć na Twój host VM Manager.

Montowanie gniazda libvirt hosta w kontenerze jest na Unraid kruche: tymi ścieżkami zarządza VM Manager, a przełączenie "Enable VMs" może sprawić, że libvirt nie będzie mógł wystartować. Klucz SSH daje uprawnienia roota na hoście, czyli ten sam poziom zaufania co gniazdo Docker, którego BombVault już używa.

Szybka konfiguracja:

1. Ustawienia, Integracje, SSH hosta: skopiuj pokazany klucz publiczny.
2. Dopisz go do pliku Unraid /root/.ssh/authorized_keys (utrwalanego też na flash, aby przetrwał restarty).
3. Kliknij Test połączenia.

Szablon dodaje --add-host=host.docker.internal:host-gateway, aby kontener mógł dotrzeć do hosta. Ustaw LIBVIRT_HOST na swoje IP Unraid w LAN, jeśli ta nazwa nie rozwiązuje się (na przykład gdy kontener działa w niestandardowej sieci br0.x). Jeśli zmieniłeś port SSH Unraid, ustaw LIBVIRT_SSH_PORT, aby pasował. Migawki na żywo dodatkowo wymagają agenta gościa qemu w VM oraz dysku na /mnt/cache (nie /mnt/user).

Pełny przewodnik konfiguracji VM i sieci

Kompletny przewodnik krok po kroku (włączenie SSH, trwała autoryzacja klucza, routing sieci niestandardowej i VLAN, metoda per VM oraz rozwiązywanie problemów po stronie hosta) znajduje się pod docs/vm-backup-ssh-setup.md na GitHub.

Konfiguracja poza siedzibą

Skonfiguruj replikę poza siedzibą na stronie Ustawienia, Poza siedzibą. Zobacz Kopie poza siedzibą i odzyskiwanie, aby poznać pełny przepływ pracy (niezmienne/append-only, tamper testy i próby DR). W skrócie:

• Backendy: SMB/CIFS i NFS (zamontuj udział i skieruj na niego Ścieżkę kopii), natywne backendy restic bez rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo) lub dowolny zdalny rclone (rclone:<remote>:<bucket>/path). Backblaze B2 nie ma tu natywnego backendu: dostęp uzyskuje się przez jego punkt końcowy S3 (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), podając identyfikator klucza i klucz aplikacji jako dane uwierzytelniające S3.
• Współdzielone dane logowania do chmury są przechowywane zaszyfrowane w Ustawienia, Dostęp do chmury, Współdzielone dane logowania do chmury.
• Cele SSH nie wymagają niczego zainstalowanego po drugiej stronie. sftp: wymaga jedynie serwera SSH. Dodaj klucz publiczny z Ustawienia, Integracje, SSH hosta (dostępny też pod /config/ssh/id_ed25519.pub) do pliku ~/.ssh/authorized_keys użytkownika docelowego.
• Kopia poza siedzibą: BombVault replikuje nowe migawki poleceniem restic copy w trybie best-effort, jako uzupełnienie (zwykle lokalnego) repozytorium podstawowego. Każda domena ma własny harmonogram poza siedzibą oraz przycisk Replikuj teraz.
• Wiele celów poza siedzibą na domenę: każda domena może replikować do kilku celów poza siedzibą naraz. Dodaj dodatkowe cele w Ustawienia, Poza siedzibą, każdy z własnym repozytorium, klasą pamięci S3, flagą append-only, przechowywaniem i budżetem wzrostu; wszystkie replikują zgodnie z harmonogramem poza siedzibą tej domeny. Istniejąca pojedyncza konfiguracja poza siedzibą jest przenoszona jako pierwszy cel.
• Miejsca docelowe: miejsca docelowe poza siedzibą ustawia się raz w Ustawienia, Poza siedzibą, Miejsca docelowe, przez kreator, który wymienia każdą obsługiwaną usługę. Zobacz Miejsca docelowe.
• Rozmieszczenie per element: każdy kontener, VM i zestaw folderów podświetla Lokalne oraz cele, które dostają jego kopie. Ustawienia, Pamięć, Domyślne rozmieszczenie ustala to per domena dla elementów bez własnego wyboru. Zobacz Rozmieszczenie per element.
• Przechowywanie per źródło: zarówno polityka lokalna, jak i polityka poza siedzibą znajdują się w Ustawienia, Przechowywanie (pozostaw politykę poza siedzibą całą na zero, aby nigdy nie przycinać automatycznie migawek poza siedzibą). Karty Przechowywanie lokalne i Przechowywanie poza siedzibą mają każda Reguły przechowywania dla źródła, które dają kontenerom, VM, flash, folderom, ZFS lub kopii własnej własne reguły przechowywania, dla ich kopii lokalnych i dla ich repo poza siedzibą. Źródło bez nich stosuje wspólne, a przechowywanie po każdej kopii, kopiowanie poza siedzibę, ręczne czyszczenie i podgląd przechowywania używają reguł źródła, którego dotyczą. Dodatkowe cele poza siedzibą zachowują reguły ustawione dla nich w Ustawienia, Poza siedzibą.
• Limity przepustowości: ogranicz tempo wysyłania/pobierania restic w Ustawienia, Poza siedzibą.
• Najpierw streaming: w Ustawienia, Poza siedzibą wybierz serwery multimediów (Plex, Jellyfin i Emby są wstępnie wybrane po nazwie obrazu), szybkość wysyłania, od której serwer uznaje się za streamujący, limit wysyłania podczas streamingu i po jakim czasie od końca streamu wraca zwykły limit.
• Zimna i archiwalna klasa pamięci (S3): dla natywnego repozytorium S3 poza siedzibą wybierz warstwę czytelną przy przywracaniu (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). Zdalne rclone ustawiają swoją klasę w konfiguracji rclone.
• Zdalne repozytorium podstawowe zamiast lokalnego: sama Ścieżka kopii domeny może być jednym z powyższych backendów, bez kopii lokalnej i bez kroku replikacji. Wbudowany przełącznik Lokalne/Zdalne i jego ustawienia bezpieczeństwa (przepustowość, append-only, budżet wzrostu) opisuje sekcja Zdalne repozytoria podstawowe.

Anomalie

Wykrywanie anomalii ustawiasz na karcie Anomalie w Ustawienia, Integralność. Każda kontrolka zapisuje się od razu po zmianie, a trzy pod przełącznikiem są ukryte, gdy wykrywanie jest wyłączone.

Ustawienie	Domyślnie	Co robi
Wykrywaj anomalie	Włączone	Porównuje każdą kopię z własną historią elementu. Po wyłączeniu nic nowego nie jest sprawdzane, a pozycja Anomalie znika z paska bocznego; karta nadal prowadzi do wcześniejszych wykryć.
Czułość	Zrównoważona	Surowa zgłasza mniejsze zmiany, Łagodna tylko duże.
Wysyłaj powiadomienie dla	Tylko krytyczne znaleziska	Najniższa waga, która wysyła wiadomość przez kanały skonfigurowane w Powiadomienia. Powtarzające się nieudane kopie i zrzuty oraz nieudane zaplanowane kontrole przywracania wysyłają już własną wiadomość i nie są wysyłane podwójnie.
Zachowuj stare kopie, gdy źródło mocno się kurczy lub zostaje nadpisane	Włączone	Dopóki element ma otwarte wykrycie prawie pustego źródła, silnego skurczenia lub ponownego zapisania większości danych, retencja i czyszczenie nie ruszają jego starych kopii. Potwierdź wykrycie lub oznacz je jako oczekiwane, aby je zwolnić.

Każdy element może mieć własną czułość i własne minimum powiadomień. Ustawisz je na stronie Anomalie, gdzie element z otwartymi ustaleniami ma je pod Monitorowanie na swojej karcie, a każdy inny element otwiera je z karty Nic otwartego, albo w panelu samego elementu: w sekcji folderów kontenera i w ustawieniach maszyny wirtualnej (obie w trybie zaawansowanym), w edytorze folderów zestawu folderów oraz na stronach Flash i Autokopia. W przypadku elementu ZFS są w jego edytorze na stronie ZFS i obowiązują każdy zbiór danych jego drzewa.

Przenośne ustawienia (eksport i import)

Karta Eksport / import ustawień na stronie Ustawienia, System zapisuje całą Twoją konfigurację BombVault (ustawienia domen, cele poza siedzibą, harmonogramy, przechowywanie, powiadomienia) do przenośnego pliku JSON, który możesz zaimportować na innej instancji, więc przeniesienie na nową maszynę lub sklonowanie konfiguracji nie oznacza ponownego wpisywania wszystkiego ręcznie. Import pokazuje podgląd i prosi o potwierdzenie oraz nigdy nie narusza Twoich danych ani historii kopii.

Eksport może zawierać poświadczenia

Sam decydujesz, czy dołączyć do pliku poświadczenia poza siedzibą, powiadomień i brokera MQTT. Z dołączonymi poświadczeniami eksport jest tak samo wrażliwy jak Twój zestaw odzyskiwania, więc przechowuj go w bezpiecznym miejscu. Bez nich plik zawiera tylko niesekretne ustawienia.