Konfiguration

Diese Seite behandelt die Umgebungsvariablen des Containers, die vom Template bereitgestellten Mounts, das VM-Backup über SSH und die Off-site-Einrichtung. Backup-Repository-Pfade werden in der App konfiguriert (Einstellungen, Speicher, Backup-Pfade), nicht über Umgebungsvariablen.

Umgebungsvariablen

Variable	Erforderlich	Beschreibung
APP_KEY	Ja	32-Byte-Hex-Geheimnis (64 Hex-Zeichen) zum Ableiten des restic-Repo-Passworts. Erzeuge es mit openssl rand -hex 32. Bewahre es sicher auf: geht es verloren, sind verschlüsselte Backups unwiederbringlich.
LIBVIRT_HOST	Für VMs	Über SSH erreichter Unraid-Host für das VM-Backup (Standard host.docker.internal; das Template füllt einen LAN-IP-Platzhalter vor). Nutze deine Unraid-LAN-IP, erforderlich in einem benutzerdefinierten br0.x-Netzwerk. Auch für ZFS-Dataset-Backups genutzt (Template-Feld Host SSH: Address); der Platzhalter 192.168.x.x gilt als nicht gesetzt.
LIBVIRT_SSH_PORT	Nein	Host-SSH-Port für das VM-Backup (Standard 22). Template-Feld Host SSH: Port, auch für ZFS-Datasets.
LIBVIRT_SSH_USER	Nein	SSH-Benutzer auf dem Host für das VM-Backup (Standard root). Template-Feld Host SSH: User, auch für ZFS-Datasets.
LIBVIRT_URI	Nein	Vollständige libvirt-Verbindungs-URI, wird wortwörtlich verwendet statt sie aus den drei obigen LIBVIRT_*-Variablen zusammenzusetzen (die dann für den Verbindungsstring ignoriert werden). Standardmäßig nicht gesetzt. Wird auf TrueNAS Scale benötigt, dessen libvirtd auf einem nicht standardmäßigen Socket lauscht, den die zusammengesetzte Form nicht abbilden kann: qemu+ssh://<user>@<truenas-host>/system?socket=/run/truenas_libvirt/libvirt-sock. Siehe den TrueNAS-Scale-Abschnitt in docs/vm-backup-ssh-setup.md. Ist es eine qemu+ssh://-URI, wird jede der Variablen LIBVIRT_HOST, LIBVIRT_SSH_USER und LIBVIRT_SSH_PORT, die nicht gesetzt ist, daraus übernommen, auch für BombVaults eigene SSH-Befehle (NVRAM-Übertragung, ZFS-Datasets).
PORT	Nein	HTTP-Port (Standard 3000; nur mit HTTP_ONLY=true verwendet).
HTTPS_PORT	Nein	HTTPS-Port (Standard 3443; das Template veröffentlicht ihn 1:1, sodass die WebUI unter https://<ip>:3443 antwortet).
HTTP_ONLY	Nein	Setze true, um den selbstsignierten HTTPS-Listener zu deaktivieren und nur schlichtes HTTP auszuliefern (zur Verwendung hinter einem TLS-terminierenden Reverse Proxy).
BIND_HOST	Nein	Adresse, auf der die WebUI lauscht (Standard 0.0.0.0, alle Schnittstellen). Im Container nicht setzen, denn seine veröffentlichten Ports brauchen alle Schnittstellen; 127.0.0.1 passt für einen Lauf außerhalb von Docker. Der Healthcheck fragt dieselbe Adresse.
TRUSTED_PROXY	Nein	Kommagetrennte Adressen oder CIDR-Bereiche des Reverse Proxys vor BombVault (zum Beispiel 192.168.20.11 oder 10.0.0.0/8). Nur von diesen Stationen wird X-Forwarded-For geglaubt, und die Anmeldebremse zählt Fehlversuche dann pro echtem Client, statt alle hinter dem Proxy in einen Topf zu werfen. Nicht gesetzt (Standard) heißt: niemandem vertrauen. Ein bedingungslos geglaubter Header ließe jeden Aufrufer seinen eigenen Topf wählen.
HOST_SOURCE_ROOT	Nein	Der als Host Data eingehängte Host-Pfad (Standard /mnt). BombVault übersetzt die von Docker gemeldeten Bind-Mount-Quellen in Pfade unter diesem Mount. Nur ändern, wenn du ein anderes Host-Wurzelverzeichnis eingehängt hast.
DATA_ROOT_SEGMENTS	Nein	Kommagetrennte Pfadsegment-Namen, die eine Bind-Mount-Quelle als Backup-Daten kennzeichnen (Standard appdata, passend zu Unraids Konvention /mnt/user/appdata/<container>). Der Bind-Mount eines Containers wird für das Backup automatisch ausgewählt, wenn ein BELIEBIGES gelistetes Segment als vollständiges Pfadsegment in seiner Host-Quelle erscheint, zum Beispiel bezieht DATA_ROOT_SEGMENTS=appdata,config auch einen .../config-Bind mit ein. Siehe Backup-Quellenerkennung für die weiteren, immer aktiven Wege, wie der Datenordner eines Containers gefunden wird.
PLATFORM	Nein	Erzwingt, als welche Plattform BombVault sich selbst betrachtet, statt sie automatisch zu erkennen: unraid, generic oder truenas (Standard nicht gesetzt: erkennt Unraid automatisch, indem nach dessen dockerMan-Marker unter dem Flash-Mount gesucht wird, ansonsten generic; ein nicht erkannter Wert fällt ebenfalls auf generic zurück, was protokolliert wird). Setze sie explizit auf einem generischen Docker-Host oder TrueNAS Scale, statt dich auf die reine Unraid-Auto-Erkennung zu verlassen; das macht die generische Compose-Datei bereits so. Ändert die appdata-Fallback-Konvention, die Standard-Wiederherstellungsziele bei instanzübergreifenden Wiederherstellungen und ob die nur für Unraid vorgesehenen Benachrichtigungs- und Begleit-Plugin-Schritte überhaupt versucht werden (siehe internal/platform).
BOMBVAULT_SELF_CONTAINER	Nein	Der Name des BombVault-Containers selbst, sodass er sich nie selbst sichert (und damit stoppt).
BACKUP_MAX_HOURS	Nein	Maximale Echtzeit-Stunden, die ein einzelner Backup-Lauf seinen Bereichs-Lock halten darf, bevor er zwangsweise abgebrochen wird (ein Schutz, damit ein verklemmter Lauf den Bereich nicht für immer blockieren kann). Leer (der Standard) verwendet 48. Erhöhe es für sehr große oder langsame Cloud-Backups (ein am Limit abgebrochener Lauf schlägt mit context deadline exceeded fehl). Setze 0, um das Limit ganz zu deaktivieren.
BACKUP_STALL_HOURS	Nein	Stunden, die ein Backup überhaupt keinen Fortschritt machen darf, bevor es abgebrochen wird. Leer (der Standard) verwendet 2; setze 0, um bei Stillstand nie abzubrechen. Das ist der feinere der beiden Schutzmechanismen und meist der, der greift: Er achtet darauf, ob noch etwas passiert, nicht darauf, wie lange der Lauf schon dauert. Ein langsames, aber gesundes Backup über mehrere Terabyte bleibt also in Ruhe, während eines, das an einer nicht antwortenden Freigabe hängt, nach Stunden statt nach Tagen gestoppt wird. Nach 30 Minuten Stille wird eine Warnung protokolliert, bevor irgendetwas abgebrochen wird. Scannen zählt als Fortschritt: restic schreibt keine Bytes, während es einen großen Baum durchläuft, und diese Phase wird über die Datei- und Byte-Summen beobachtet statt über die geschriebenen Bytes. Die beiden Variablen sind unabhängig voneinander, und BACKUP_MAX_HOURS begrenzt weiterhin die Phasen nach dem eigentlichen Backup (Aufbewahrung, Statistiken, Off-site-Kopie), in denen es keine Zähler zu beobachten gibt.
DB_DUMP_MAX_HOURS	Nein	Stunden, die ein automatischer Datenbank-Dump laufen darf, bevor er abgebrochen wird. Leer (der Standard) verwendet 6; erlaubt sind 1 bis 48, und das Limit bleibt eine Stunde unter BACKUP_MAX_HOURS (bei weniger als zwei Stunden bei der Hälfte davon), damit ein langer Dump an seinem eigenen Limit endet und als solcher gemeldet wird, statt das Backup mitzureißen. Ein Dump, der nicht mehr vorankommt, wird schon nach BACKUP_STALL_HOURS gestoppt. Ein gestoppter Dump schlägt für sich fehl, das Backup des Containers läuft weiter. Auf Unraid fügst du die Variable dem BombVault-Container mit Add another Path, Port, Variable hinzu.
TZ	Nein	Zeitzone für den Planer (zum Beispiel Europe/Berlin). Nicht gesetzt bedeutet, dass alle Zeitpläne in UTC laufen: ein Plan mit 02:30 startet dann um 02:30 UTC und nicht nach der lokalen Uhrzeit. Auf Unraid setzt du das nie selbst: Das System gibt seine eigene Zeitzone an jeden Container weiter. Das Startprotokoll nennt die Zone, die dabei ermittelt wurde. Eine Zone mit Sommerzeit lässt im Frühjahr einen Lauf aus und führt im Herbst einen doppelt aus; UTC tut beides nicht, verschiebt sich dafür aber zweimal im Jahr um eine Stunde gegenüber deiner Uhr.

Mounts

Hänge den Docker-Socket, den Flash (/boot) und das Wurzelverzeichnis Host Data (/mnt) ein, wie im CA-Template gezeigt. Backup-Quellen und -Ziele liegen beide unter Host Data, und es ist slave eingehängt, sodass eine Remote-Freigabe, die nach dem Containerstart eingehängt wird (zum Beispiel unter /mnt/remotes), ohne Neustart sichtbar wird.

ZFS-Dataset-Backups brauchen diesen Modus ebenfalls: Den Snapshot eines Datasets hängt der Host erst ein, nachdem der Container gestartet ist. Siehe ZFS-Datasets.

Backup-Repository-Pfade sind standardmäßig /mnt/user/bombvault/{container,vms,flash,config,files,zfs}, angelegt beim ersten Backup. Ändere den Ort jederzeit unter Einstellungen, Speicher, Backup-Pfade. Jedes Pfadfeld hat außerdem einen Schalter Lokal / Remote direkt daneben: Ein Pfad kann statt eines lokalen Ordners ein restic-Remote sein (s3:..., rest:..., sftp:..., rclone:...), und BombVault sichert dann direkt dorthin, ohne getrennte lokale Kopie; siehe Entfernte primäre Repositories.

Host-Integration-Check

Öffne /spike in der Web-Oberfläche, nachdem der Container gestartet ist. Es prüft jeden Mount und jedes CLI (Docker-Socket, libvirt, restic, qemu-img, rclone) und meldet fehlende Teile.

Erkennung der Sicherungsquellen

Für jeden Container wählt BombVault selbst aus, welche Bind-Mounts und benannten Volumes gesichert werden. Ein Pfad wird übernommen, sobald einer der folgenden Punkte zutrifft (das Ergebnis lässt sich pro Container jederzeit unter Gesicherte Ordner überschreiben):

• Treffer auf ein Datenwurzel-Segment: die Host-Quelle des Binds enthält eines der Segmente aus DATA_ROOT_SEGMENTS als vollständige Pfadkomponente (voreingestellt nur appdata).
• Benannte Docker-Volumes werden immer eingeschlossen, denn zu ihnen gibt es kein wegwerfbares Gegenstück und damit nichts zu filtern, aber nur, wenn der echte Host-Speicherpfad des Volumes selbst über den Host-Data-Mount erreichbar ist, genau wie jeder andere Host-Pfad, den BombVault sichert. Der Standardtreiber für lokale Volumes legt ein Volume unterhalb der Datenwurzel des Docker-Daemons ab, also /var/lib/docker/volumes/<name>/_data, sofern das nicht angepasst wurde (nachsehen mit docker info -f '{{.DockerRootDir}}'). Dieser Ort liegt NICHT im schmalen Ein-Verzeichnis-Host-Data-Mount, den die generische docker-compose.yml standardmäßig verwendet. Ein nicht erreichbares Volume wird stillschweigend übersprungen und nicht als Fehler gemeldet. Damit benannte Volumes auf einem generischen Host wirklich gesichert werden, richte Host Data (und HOST_SOURCE_ROOT) auf einen gemeinsamen übergeordneten Ordner, der auch die Docker-Datenwurzel abdeckt. Die Abwägung dazu steht im Host-Data-Kommentar der Compose-Datei (Unraid umgeht das, indem es aus demselben Grund gleich ganz /mnt einhängt, seine eigene allgemeingültige Konvention auf oberster Ebene).
• Projektverzeichnis von Docker Compose: trägt der Container das übliche Label com.docker.compose.project.working_dir (von docker compose up automatisch gesetzt), kommt dieses Verzeichnis ebenfalls dazu, unabhängig davon, ob irgendein Bind auf ein Datenwurzel-Segment gepasst hat.
• Label-Übersteuerung bombvault.data: setze am Container das Label bombvault.data=true, um ALLE seine Bind-Mounts einzuschließen, für ein Layout, das keine der beiden Konventionen oben erfasst (etwa ein einzelner Bind /srv/plex/config ohne Compose-Projekt). Jeder nicht leere Wert außer false gilt als wahr; ein fehlendes Label oder bombvault.data=false ändert nichts.
• Label bombvault.dbdump: setze bombvault.dbdump=false an einem Container, um seinen automatischen Datenbank-Dump abzuschalten (0, no und off wirken genauso), oder nenne die Engine (postgres, mysql, mariadb), um einen Container zu dumpen, den BombVault von sich aus nicht erkennt. Das Label sticht den Schalter auf der Karte des Containers, der auf Unraid der übliche Weg ist.

Sicherheitsmodell

Root-äquivalente Kontrolle über den Host

Über den Docker-Socket kann BombVault Container stoppen, entfernen und neu erstellen sowie Appdata lesen/schreiben, und für das VM-Backup meldet es sich über SSH am Host an (qemu+ssh://, standardmäßig root), um virsh auszuführen. Wer die Web-Oberfläche erreichen kann, hat praktisch Root-Rechte auf dem Host.

• Optionaler Passwortschutz (Einstellungen, Sicherheit): setze ein Passwort, um Login zu verlangen, lösche es, um zu deaktivieren. Standardmäßig aus für die Nutzung im vertrauenswürdigen LAN. Das Passwort wird mit Argon2id über einen mit APP_KEY gepfefferten Wert gespeichert, ein kopiertes /config ist ohne den Schlüssel also wertlos und mit ihm langsam anzugreifen. Ein neues Passwort braucht mindestens 12 Zeichen; ein vorhandenes kürzeres funktioniert weiter, bis es geändert wird. Sitzungen sind signiert (HMAC abgeleitet aus APP_KEY), und eine Passwortänderung macht sie ungültig; Anmeldungen sind auf fünf Fehlversuche pro Minute und Client begrenzt.
• Zwei-Faktor-Anmeldung (Einstellungen): ein Zeitcode aus einer Authenticator-App zusätzlich zum Passwort, dazu acht einmalige Notfallcodes, die beim Einschalten einmal ausgegeben werden. Das gemeinsame Geheimnis liegt mit APP_KEY verschlüsselt, und das Ausschalten verlangt einen aktuellen Code.
• Passkeys (WebAuthn) bekommen eine eigene Karte, sobald ein Passwort gesetzt ist. Sie gelten zusätzlich zum Passwort und ersetzen es nie, wer alle Passkeys entfernt, sperrt also niemanden aus. Sie brauchen einen echten Domainnamen und ein Zertifikat, dem der Browser vertraut. Das voreingestellte https://<ip>:3443 ist genau das, was WebAuthn ablehnt, und die Karte sagt das, statt einen Knopf anzubieten, der dann fehlschlägt.
• Änderungen brauchen JSON. Eine Anfrage, die etwas ändert, muss Content-Type: application/json senden und darf vom Browser nicht als seitenübergreifend markiert sein. So kann eine Seite auf einer anderen Website deinen Browser keine Einstellungen an einer LAN-Adresse ändern lassen. Ein Skript, das die API ansteuert, sendet diesen Header; alles andere wird mit 415 abgelehnt.
• Weil die Sperre Opt-in ist, sind bei nicht gesetztem Passwort die gesamte UI und API (einschließlich der Off-site-Einrichtung, der Manipulationstest-Routen und des Recovery-Kits) für jeden erreichbar, der den Port erreichen kann. Aktiviere die Sperre, sobald Off-site-, unveränderliche Backups oder Verschlüsselung im Einsatz sind.
• Betreibe BombVault nur in einem vertrauenswürdigen, nicht exponierten Netzwerk. Für Fernzugriff setze es hinter einen Reverse Proxy, der Authentifizierung und TLS ergänzt. Antworten tragen grundlegende Sicherheits-Header (CSP, nosniff, X-Frame-Options, Referrer-Policy).
• Hinter einem Reverse Proxy trägt jede Anfrage die Adresse des Proxys, ohne TRUSTED_PROXY zählt die Anmeldebremse also alle Clients in einen Topf und die Fehlversuche eines Angreifers sperren auch dich aus. Trage den Proxy in TRUSTED_PROXY ein, dann zählt sie wieder pro Client.
• Ein Reverse Proxy vor BombVault muss den Authorization- oder X-API-Key-Header an /mcp durchreichen und darf die Antworten nicht puffern, sonst können sich Assistenten nicht verbinden. Siehe MCP-Server.
• Der MCP-Endpunkt /mcp antwortet mit 404, bis ein Schlüssel existiert oder die Anmeldung über OAuth eingeschaltet ist, und er verlangt von jedem Client dessen Schlüssel oder Token, auch wenn das Anmeldepasswort aus ist; keine Adresse ist davon ausgenommen, auch nicht localhost. Er hat keine Werkzeuge zum Wiederherstellen oder Löschen, und das Wiederherstellen eines Konfigurations-Backups widerruft jeden Schlüssel. Siehe MCP-Server.
• Mit HTTP_ONLY=true verliert das Session-Cookie sein Secure-Flag (das muss es, um über schlichtes HTTP zu funktionieren), aktiviere das Passwort also nur hinter einem TLS-terminierenden Proxy, wenn Vertraulichkeit wichtig ist.
• Die SSH-Verbindung für das VM-Backup vertraut dem Host-Key beim ersten Verbinden (TOFU) und pinnt ihn danach. Verifiziere den Host-Key außerhalb des Kanals, wenn dein Pfad vom Container zum Host nicht vertrauenswürdig ist.
• Backups werden von restic verschlüsselt, wenn die Verschlüsselung aktiviert ist (Einstellungen; standardmäßig an), mit dem aus APP_KEY abgeleiteten Schlüssel.

MCP-Server

Der MCP-Server braucht keine Umgebungsvariable. Du schaltest ihn ein, indem du unter Einstellungen, Anbindungen, MCP-Server einen Schlüssel anlegst, und er antwortet unter /mcp auf demselben Port wie die Web-Oberfläche (zum Beispiel https://192.168.1.10:3443/mcp). Ohne aktiven Schlüssel antwortet dieser Pfad mit 404. Clients, Zertifikate und Grenzen beschreibt die Seite MCP-Server.

VM-Backup über SSH

BombVault sichert KVM/libvirt-VMs, ohne irgendeinen libvirt-Pfad einzuhängen. Es führt virsh auf dem Host über SSH aus (qemu+ssh://), sodass es deinen Host-VM-Manager niemals beeinträchtigen kann.

Den libvirt-Socket des Hosts in einen Container einzuhängen ist auf Unraid fragil: Diese Pfade gehören dem VM Manager, und das Umschalten von "Enable VMs" kann libvirt in einem Zustand zurücklassen, in dem es nicht mehr startet. Der SSH-Schlüssel gewährt Root auf dem Host, dieselbe Vertrauensstufe wie der Docker-Socket, den BombVault ohnehin nutzt.

Schnelleinrichtung:

1. Einstellungen, Anbindungen, Host-SSH: kopiere den angezeigten öffentlichen Schlüssel.
2. Hänge ihn an Unraids /root/.ssh/authorized_keys an (auch auf dem Flash gespeichert, damit er Neustarts überdauert).
3. Klicke auf Verbindung testen.

Das Template fügt --add-host=host.docker.internal:host-gateway hinzu, damit der Container den Host erreichen kann. Setze LIBVIRT_HOST auf deine Unraid-LAN-IP, falls dieser Name nicht auflöst (zum Beispiel, wenn der Container in einem benutzerdefinierten br0.x-Netzwerk läuft). Wenn du Unraids SSH-Port geändert hast, setze LIBVIRT_SSH_PORT passend. Live-Snapshots benötigen zusätzlich den qemu-Gast-Agenten in der VM und den Datenträger auf /mnt/cache (nicht /mnt/user).

Vollständige Anleitung zu VM-Einrichtung und Netzwerk

Die komplette Schritt-für-Schritt-Anleitung (SSH-Aktivierung, persistente Schlüsselautorisierung, Routing für benutzerdefinierte Netzwerke und VLANs, Methode pro VM und host-seitige Fehlerbehebung) findest du unter docs/vm-backup-ssh-setup.md auf GitHub.

Off-site-Einrichtung

Richte eine Off-site-Replik auf der Seite Einstellungen, Off-site ein. Siehe Off-site & Wiederherstellung für den vollständigen Ablauf (unveränderlich/append-only, Manipulationstest und DR-Übungen). Kurz gefasst:

• Backends: SMB/CIFS und NFS (Freigabe einhängen und einen Backup-Pfad darauf richten), native restic-Backends ohne rclone (s3:..., rest:http://host:8000/repo, sftp:user@host:/repo) oder jedes rclone-Remote (rclone:<remote>:<bucket>/path). Backblaze B2 hat hier kein eigenes Backend: Es wird über seinen S3-Endpunkt angesprochen (s3:https://s3.<region>.backblazeb2.com/<bucket>/<path>), mit der Schlüssel-ID und dem Anwendungsschlüssel als S3-Zugangsdaten.
• Geteilte Cloud-Zugangsdaten werden verschlüsselt gespeichert unter Einstellungen, Cloud-Zugänge, Geteilte Cloud-Zugangsdaten.
• SSH-Ziele brauchen auf der Gegenseite nichts installiert. sftp: benötigt nur einen SSH-Server. Füge den öffentlichen Schlüssel aus Einstellungen, Anbindungen, Host-SSH (auch unter /config/ssh/id_ed25519.pub) den ~/.ssh/authorized_keys des Zielbenutzers hinzu.
• Off-site-Kopie: BombVault repliziert neue Snapshots mit restic copy auf Best-Effort-Basis, zusätzlich zu einem (meist lokalen) primären Repo. Jeder Bereich hat seinen eigenen Off-site-Zeitplan, plus einen Button Jetzt replizieren.
• Mehrere Off-site-Ziele pro Bereich: jeder Bereich kann gleichzeitig an mehrere Off-site-Ziele replizieren. Füge zusätzliche Ziele unter Einstellungen, Off-site hinzu, jedes mit eigenem Repository, S3-Speicherklasse, Append-only-Flag, Aufbewahrung und Wachstumsbudget; sie alle replizieren nach dem Off-site-Zeitplan dieses Bereichs. Eine bestehende einzelne Off-site-Einrichtung wird als erstes Ziel übernommen.
• Ziele: Off-site-Ziele richtest du einmal unter Einstellungen, Off-site, Ziele ein, mit einem Assistenten, der jeden unterstützten Dienst auflistet. Siehe Ziele.
• Ablage pro Element: jeder Container, jede VM und jedes Ordner-Set schaltet Lokal und die Ziele ein, die seine Backups bekommen. Einstellungen, Speicher, Ablage-Vorgaben legt das pro Bereich für Elemente ohne eigene Wahl fest. Siehe Ablage pro Element.
• Aufbewahrung pro Quelle: die lokale und die Off-site-Richtlinie liegen beide unter Einstellungen, Aufbewahrung (lasse die Off-site-Richtlinie ganz auf null, um Off-site-Snapshots nie automatisch zu kürzen). Die Karten Lokale Aufbewahrung und Off-site-Aufbewahrung haben je Aufbewahrung je Quelle, womit Container, VMs, Flash, Ordner, ZFS oder das Selbst-Backup eigene Aufbewahrungsregeln bekommen, für ihre lokalen Backups und für ihr Off-site-Repo. Eine Quelle ohne eigene Regeln folgt den gemeinsamen, und die Aufbewahrung nach jedem Backup, die Off-site-Kopie, ein manuelles Aufräumen und die Aufbewahrungsvorschau nutzen alle die Regeln der Quelle, um die es geht. Weitere Off-site-Ziele behalten die Regeln, die unter Einstellungen, Off-site für sie eingestellt sind.
• Bandbreitenlimits: begrenze die restic-Upload-/Download-Rate unter Einstellungen, Off-site.
• Streaming zuerst: unter Einstellungen, Off-site wählst du die Mediaserver (Plex, Jellyfin und Emby sind nach Image-Namen vorausgewählt), die Senderate, ab der einer als streamend gilt, die Upload-Grenze während des Streams und wie lange nach einem Stream die normale Grenze zurückkommt.
• Kalt- und Archiv-Speicherklasse (S3): wähle für ein natives S3-Off-site-Repo eine wiederherstellungslesbare Stufe (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval). rclone-Remotes setzen ihre Klasse in der rclone-Konfiguration.
• Entferntes statt lokales primäres Repo: Der Backup-Pfad eines Bereichs kann selbst eines der Backends oben sein, ohne lokale Kopie und ohne Replikationsschritt. Den Schalter Lokal/Remote direkt am Feld und seine Sicherheitseinstellungen für Bandbreite, Append-only und Wachstumsbudget beschreibt Entfernte primäre Repositories.

Anomalien

Die Anomalie-Erkennung stellst du in der Karte Anomalien unter Einstellungen, Integrität ein. Jedes Bedienelement speichert sofort, und die drei unter dem Schalter sind ausgeblendet, solange die Erkennung aus ist.

Einstellung	Standard	Wirkung
Anomalien erkennen	An	Vergleicht jedes Backup mit dem eigenen Verlauf des Elements. Ausgeschaltet wird nichts Neues mehr geprüft und der Eintrag Anomalien verschwindet aus der Seitenleiste; die Karte verlinkt weiter auf frühere Funde.
Empfindlichkeit	Ausgewogen	Streng meldet schon kleinere Änderungen, Nachsichtig nur große.
Benachrichtigen bei	Nur kritische Funde	Der niedrigste Schweregrad, der über die unter Benachrichtigungen eingerichteten Kanäle eine Nachricht schickt. Wiederholt fehlgeschlagene Backups und Dumps sowie fehlgeschlagene geplante Wiederherstellungsprüfungen schicken schon eine eigene Nachricht und werden nicht doppelt gemeldet.
Alte Backups behalten, wenn eine Quelle stark schrumpft oder neu geschrieben wird	An	Solange ein Element einen offenen Fund zu einer fast leeren Quelle, einem starken Schrumpfen oder zu neu gespeicherten Daten hat, lassen Aufbewahrung und Aufräumen die alten Backups dieses Elements in Ruhe. Quittiere den Fund oder markiere ihn als erwartet, damit sie wieder gelöscht werden dürfen.

Jedes Element kann eine eigene Empfindlichkeit und ein eigenes Benachrichtigungsminimum haben. Du stellst sie auf der Seite Anomalien ein, wo ein Element mit offenen Funden sie unter Überwachung auf seiner Karte hat und jedes andere Element sie aus der Karte Ohne offene Funde öffnet, oder im Panel des Elements selbst: im Ordnerbereich eines Containers und in den Einstellungen einer VM (beides im erweiterten Modus), im Ordner-Editor eines Ordner-Sets und auf den Seiten Flash und Selbst-Backup. Bei einem ZFS-Element stehen sie in seinem Editor auf der Seite ZFS und gelten für jedes Dataset seines Baums.

Portable Einstellungen (Export und Import)

Die Karte Einstellungen exportieren / importieren auf der Seite Einstellungen, System schreibt deine gesamte BombVault-Konfiguration (Bereichseinstellungen, Off-site-Ziele, Zeitpläne, Aufbewahrung, Benachrichtigungen) in eine portable JSON-Datei, die du auf einer anderen Instanz importieren kannst, sodass ein Umzug auf eine neue Box oder das Klonen eines Setups nicht bedeutet, alles von Hand neu einzugeben. Der Import zeigt eine Vorschau und fragt nach Bestätigung und rührt niemals deine Backup-Daten oder -Historie an.

Der Export kann Zugangsdaten enthalten

Du wählst, ob die Off-site-, Benachrichtigungs- und MQTT-Broker-Zugangsdaten in der Datei enthalten sein sollen. Mit enthaltenen Zugangsdaten ist der Export so sensibel wie dein Recovery-Kit, also bewahre ihn an einem sicheren Ort auf. Ohne sie hält die Datei nur nicht-geheime Einstellungen.