Funktionen

BombVault ist standardmäßig einfach und tiefgehend, wenn du es brauchst. Die Oberfläche zeigt nur das Wesentliche, bis du den Schalter Einfache Ansicht / Erweiterte Ansicht umlegst. Diese Seite gruppiert den vollständigen Funktionsumfang.

Backup-Umfang

Container, jeder mit eigenem Zeitplan-Schalter, Sicherungsreihenfolge und eigener Historie.

Was	Was gesichert wird
Docker-Container	Appdata-Verzeichnis plus die Container-Definition (Image, Umgebungsvariablen, Ports, Labels, Volumes). Standardmäßig das ganze Appdata-Verzeichnis; mit Ordner auswählen am Container hakst du genau die Ordner an, die das Backup abdeckt, mit einer laufenden Zählung der Pfade, einer Liste dessen, was du ausgelassen hast, und einem Schalter Cache-Ordner überspringen pro Wurzel (CACHEDIR.TAG).
KVM / libvirt-VMs	VM-Datenträger-Image(s), XML-Definition und UEFI-NVRAM (geordnetes Herunterfahren oder Live-Snapshot, über SSH). Live-Snapshots fallen automatisch auf ein geordnetes Backup zurück, wenn der Snapshot nicht erstellt werden kann, sodass ein VM-Backup niemals einfach mit einem Fehler abbricht. Mit Nur geänderte Blöcke wird eine laufende VM mit qcow2-Platten über libvirt-Checkpoints gelesen: Ein Backup liest nur die Blöcke, die seit dem letzten geschrieben wurden, und jeder Snapshot stellt trotzdem die ganze Platte für sich allein wieder her. Platten auf ZFS-Zvols werden mit zfs send über dieselbe SSH-Verbindung gestreamt, sodass eine VM, deren Platten Zvols sind, als eine VM gesichert wird. Der Zustand eines durchgereichten vTPM wird neben dem NVRAM gespeichert, wenn die Domain-XML seinen Pfad nennt. Ein emuliertes vTPM, wie es TrueNAS für Windows-11-Gäste einrichtet, gibt diesen Pfad nicht preis, halte den Wiederherstellungsschlüssel eines solchen Gasts also griffbereit. Siehe die Anleitung zum VM-Backup.
Unraid-Flash	Der gesamte USB-Flash (/boot): OS, Lizenz, Array-Konfiguration, Freigaben, Netzwerk- und Plugin-Konfiguration. Die Wiederherstellung ist ein Ein-Klick-.zip-Download und überschreibt niemals den laufenden Flash.
App-Konfiguration	BombVaults eigenes /config (Einstellungsdatenbank, Off-site-Zugangsdaten, libvirt-SSH-Schlüsselpaar), mit SQLite VACUUM INTO als Snapshot gesichert, sodass eine Datenbank im WAL-Modus nie mitten im Schreibvorgang erfasst wird. Wird per Selbst-Neustart wiederhergestellt, sodass die laufende Datenbank nie unter einem offenen Handle überschrieben wird.
Dateien & Ordner	Benannte Dateisätze: jeder beliebige Ordner auf dem Server (eine Freigabe, deine Dokumente, eine Fotobibliothek), jeweils mit optionalen Ausschlussmustern pro Satz. Volle Gleichwertigkeit mit den anderen Bereichen (Zeitpläne, Aufbewahrung, Off-site-Kopie, Integritätsprüfungen und Wiederherstellungsübungen).
ZFS-Datasets	Ein Dataset zusammen mit allen Datasets darunter, gelesen aus einem einzigen ZFS-Snapshot, sodass alle vom selben Augenblick stammen, und mit restic gespeichert wie ein Ordner: dedupliziert, durchsuchbar, einzelne Dateien wiederherstellbar. Neue Unter-Datasets kommen von selbst dazu, einzelne lassen sich auslassen, und ein Unter-Dataset, das nicht lesbar ist, wird übersprungen und benannt. Auf Wunsch werden Container nur für den Augenblick des Snapshots gestoppt oder ein Befehl ausgeführt. Volumes gehören nicht dazu: Das Volume einer VM wird mit seiner VM gesichert, ein Volume ohne VM wird noch nicht gesichert. Siehe ZFS-Datasets.

Wiederherstellung

Die geführte Wiederherstellung nimmt eine frische Installation an einer Stelle durch den Ernstfall.

• Ein-Klick-Vollwiederherstellung. Snapshot wählen, auf Wiederherstellen klicken. Fertig.
• Eine Zeitleiste pro Element. Container, VMs, Ordner-Sets, der Flash und die App-Konfiguration listen ihre Backups als eine Zeitleiste über jeden Ort, an dem sie liegen, das Repository, in das sie geschrieben werden, und jedes Off-site-Ziel. Ein ins Off-site kopiertes Backup erscheint einmal, markiert mit jedem Ort. Off-site-Orte werden gelesen, wenn du sie öffnest, und das Löschen an einem Ort sagt, ob es die letzte Kopie war.
• Container werden automatisch neu installiert. Die Container-Definition wird gegen die Docker-API eingespielt, sodass der Container exakt wie zuvor wieder im Unraid-Docker-Tab erscheint.
• GPU, Limits und Links kommen zurück. Ein wiederhergestellter Container bekommt seine Ressourcen-Limits, seinen Log-Treiber, seine DNS-Einstellungen, alte Links und seine GPU oder Laufzeit (--gpus, --runtime=nvidia) zurück. Fehlt dem Host dieser GPU-Treiber oder diese Laufzeit, sagt die Wiederherstellung das und bietet Ohne GPU und Laufzeit wiederherstellen an, auch nach dem Wiederherstellen mehrerer Container oder eines Stacks. Ein Link zu einem Container, der fehlt oder beim Start des wiederhergestellten gestoppt ist, entfällt, und der Lauf-Verlauf sagt es.
• VMs werden automatisch neu erstellt. Die XML wird über SSH neu importiert, sodass die VM mit angehängtem Datenträger und UEFI-NVRAM wieder im VM Manager erscheint, selbst nachdem die VM gelöscht wurde. Backups entdecken baut einen vollständig verschwundenen Eintrag neu auf (zum Beispiel nach einer Neuinstallation).
• Einzelwiederherstellung. Stelle einen Container, eine VM oder einen Dateisatz wieder her, ohne die anderen anzurühren.
• Die Flash-Wiederherstellung ist ein .zip-Download. Sie wird als flash-<id>.zip in deinen Browser gestreamt, bereit zum Einwerfen in den Unraid-USB-Ersteller. Der laufende /boot wird nie angerührt.
• Plugins einzeln. Die Flash-Seite listet die Plugins jedes Flash-Backups mit Version und Größe auf und legt ein einzelnes zurück in den laufenden Flash: seine .plg-Datei, seinen Ordner unter config/plugins und die Paketdateien, die das Backup enthält. Sonst ändert sich nichts auf dem Flash. Unraid installiert das Plugin beim nächsten Start oder sofort unter Plugins, Install Plugin.
• Geplanter Flash-ZIP-Export. Nach jedem Flash-Backup optional den Snapshot als schlichtes .zip in einen von dir gewählten Ordner schreiben (eine einzelne überschriebene flash-latest.zip oder eine rollierende Historie). Richte es auf einen Syncthing- oder rclone-Ordner, sodass dein bootfähiges USB-Backup den Server automatisch verlässt.
• Vorab-Konfliktprüfung. Bevor irgendetwas gestoppt oder entfernt wird, prüft die Wiederherstellung, ob die statische IP des Containers und die veröffentlichten Host-Ports frei sind, und bricht mit einer klaren Meldung ab, statt eine halbfertige Wiederherstellung zu hinterlassen.
• Prüfung vor dem Restore. Jeder Restore-Dialog prüft zuerst, ob das Repository antwortet, ob der gespeicherte Schlüssel es öffnet, ob der Wiederherstellungspunkt da ist und ob das Ziel Platz für das hat, was der Restore schreibt. Start bleibt gesperrt, solange eine Prüfung fehlschlägt, und das (i) im Knopf sagt, welche.
• Restore-Plan. Vor dem Bestätigen zeigt der Dialog, was der Restore im Vergleich zum jetzigen Stand tut: neue, ersetzte und unveränderte Dateien, die Liste auf Wunsch, und die Dateien am Ziel, die nicht im Backup sind und bleiben, wo sie sind. Bei Containern und VMs vergleicht er außerdem die Einstellungen, die der Restore anlegt, mit den laufenden: Image und Tag, Ports, Variablennamen und Volumes, bei VMs Arbeitsspeicher, vCPUs, Disks und Netzwerk. restic ermittelt das als Probelauf nach Größe und Änderungszeit, ohne die Dateien zu lesen; ein sehr großer Baum hört nach 30 Sekunden auf und sagt das. Ein Stack-Restore prüft und plant jedes Mitglied und nennt das, das ihn sperrt.
• Geteilte Ordner. Ein Restore am Originalort nennt jeden anderen Container, ob er läuft oder nicht, dessen Bind-Mount in einen Ordner reicht, in den der Restore schreibt, etwa „dieser Pfad wird auch von nextcloud-db benutzt“. Das ist ein Hinweis und sperrt nichts.
• Wiederherstellung auf Dateiebene. Klappe die Dateien eines Container-Snapshots auf, filtere, hake beliebig viele Dateien und Ordner ab und stelle die Auswahl dann an Ort und Stelle oder in einen von dir gewählten Ordner wieder her.
• Dateisatz-Wiederherstellung. Stelle einen Dateisatz-Snapshot an Ort und Stelle (nach einer ausdrücklichen Bestätigung) oder in einen von dir gewählten Ordner wieder her, niemals stillschweigend. Selektive Wiederherstellung funktioniert auch hier.
• ZFS-Dataset-Wiederherstellung. Stelle ein Dataset eines Elements an seinem Platz wieder her (nach einem ZFS-Sicherheits-Snapshot, der bleibt, bis du ihn löschst), in einen Ordner oder nur die Dateien, die du auswählst, oder alle Datasets eines Backups in einen Ordner. Ein Dataset wird nie zurückgerollt oder ersetzt.
• Die Wiederherstellung bewahrt den Laufzustand. Ein Container oder eine VM, die beim Backup lief, kommt laufend zurück; was gestoppt war, bleibt gestoppt. Hake Nach Wiederherstellung gestoppt lassen an, um ohne Start neu zu erstellen.
• Einen ganzen Stack wiederherstellen. Container aus demselben Docker-Compose-Projekt werden in einem Stacks-Panel gruppiert. Stack wiederherstellen… baut jedes Mitglied aus seinem neuesten Backup gestoppt neu auf und startet sie dann optional in depends_on-Reihenfolge.
• Live-Fortschritt, Abbruch und Beschäftigt-Rückmeldung. Eine lange Wiederherstellung zeigt einen Live-Prozentbalken und kann mit einer typbewussten Bestätigung abgebrochen werden. Eine abgebrochene Wiederherstellung wird als abgebrochen erfasst, nicht als fehlgeschlagen.
• Geführte Wiederherstellung. Ein eigener Reiter Wiederherstellung führt eine Neuinstallation durch den Katastrophenfall. Siehe Off-site & Wiederherstellung.
• Wiederherstellung aus einem anderen BombVault-Repo. Eine einmalige, schreibgeschützte Sitzung öffnet das Repo einer anderen BombVault-Instanz mit deren APP_KEY, sodass du einen Container von Server A auf Server B ziehen kannst, ohne deine eigenen Einstellungen anzurühren. Siehe Off-site & Wiederherstellung.
• ZFS-Eigenschaften kommen zurück. Jedes ZFS-Backup speichert die lokal gesetzten Eigenschaften jedes Datasets, etwa Kompression, Blockgröße, Quota und Groß-/Kleinschreibung. Eine Wiederherstellung in ein neues Dataset legt es mit ihnen an, eine Wiederherstellung in ein bestehendes Dataset zeigt sie und setzt sie nur, wenn du das willst. Siehe ZFS-Datasets.
• Import aus dem Appdata.Backup-Plugin. Auf der Seite Wiederherstellung zeigst du BombVault den Backup-Ordner des Plugins. Jedes Container-Archiv wird ein Wiederherstellungspunkt seines Containers, mit dem Datum, an dem das Plugin es erstellt hat. Schon importierte Archive werden übersprungen, und die Archive selbst werden nur gelesen. Der Container braucht vorher ein Backup in BombVault, damit die Wiederherstellung seine Definition hat. Die Aufbewahrung lässt importierte Wiederherstellungspunkte stehen, lösche also selbst einen, den du nicht mehr brauchst.

Speicher & Planung

• Inkrementelle, deduplizierte Backups über restic, sodass selbst große VM-Datenträger das Repo nicht aufblähen.
• Ziele: ein lokaler Pfad oder Off-site. SMB-Freigaben und WebDAV-Server (Nextcloud, ownCloud, SharePoint) direkt über ein Formular unter Einstellungen, Cloud-Zugänge, rclone, ohne Host-Mount; NFS (den Export auf Unraid 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 via rclone:<remote>:<bucket>/path. Alle Zugangsdaten werden verschlüsselt gespeichert.
• SSH-Ziele brauchen auf der Gegenseite nichts installiert. sftp: benötigt nur einen SSH-Server, sodass ein nackter Raspberry Pi (kein Docker, kein restic) als Off-site-Ziel funktioniert. Host-Keys werden beim ersten Kontakt automatisch gepinnt.
• Off-site-Kopie (lokal + remote). Behalte das schnelle lokale Backup und füge eine oder mehrere Off-site-Repliken hinzu, repliziert mit restic copy auf Best-Effort-Basis (ein Off-site-Aussetzer lässt das lokale Backup nie fehlschlagen). Jeder Bereich hat seinen eigenen Off-site-Zeitplan, plus einen Button Jetzt replizieren.
• Mehrere Off-site-Ziele pro Bereich. Jeder Bereich (Container, VMs, Flash, Config, Dateisätze und ZFS-Datasets) kann gleichzeitig an mehrere Off-site-Ziele replizieren, nicht nur eines. Füge zusätzliche Ziele auf der Off-site-Seite hinzu, jedes mit eigenem Repository, S3-Speicherklasse, Append-only-Flag, Aufbewahrung und Wachstumsbudget. Deine bestehende Off-site-Kopie wird als erstes Ziel übernommen, sodass sich nichts ändert, bis du ein zweites hinzufügst, und jedes Ziel eines Bereichs repliziert nach dem Off-site-Zeitplan dieses Bereichs.
• Benannte Repositories. Trag deine Backup-Orte einmal unter Einstellungen, Speicher, Repositories ein, als lokalen Pfad oder als beliebiges restic-Remote mit eigenem Zugangsdaten-Satz, und wähle dann eines davon auf der Karte eines Elements als dessen Ort. Eine Zeile zeigt, wie viele Elemente darauf zeigen, und ein Repository, das ein Element oder eine Ablage-Vorgabe nutzt, lässt sich weder verschieben noch löschen, weil BombVault ein bereits geschriebenes Backup nie verschiebt.
• Mehrere Sätze Cloud-Zugangsdaten. Die geteilten Cloud-Zugangsdaten gelten standardmäßig überall, aber jedes Ziel kann stattdessen einen benannten Zugangsdaten-Satz wählen (Einstellungen, Cloud-Zugänge, Zusätzliche Zugangsdaten-Sätze). So können ein Hetzner-S3-Bucket und ein lokaler Garage-Server nebeneinander laufen, jeder mit eigenem Schlüssel. Das gilt auch für Off-site-Ziele und für einen Backup-Pfad, der selbst ein entferntes Repository ist.
• Ziele. Ein Off-site-Ziel richtest du einmal ein, mit einem Assistenten, der S3-Speicherdienste, eigene S3-Server, eigene Server und Freigaben und jeden Cloud-Speicher auflistet, den rclone kann, samt Anmeldung, Verbindungstest, Ordnerauswahl und einer ehrlichen Auskunft zum Schutz vor Löschen. Danach steht es als Knopf bei jedem Bereich und jedem Element. Siehe Ziele.
• Ablage pro Element. Jede Container-, VM- und Ordner-Set-Karte hat eine Zeile mit Knöpfen, Lokal und einer pro Off-site-Ziel, und die eingeschalteten bekommen die Backups. Eine Freigabe, die schon auf einem NAS liegt, muss nicht zusätzlich nach B2. Der Ort ist ab dem ersten Backup fest, die Kopien können sich jederzeit ändern, und die Karte zeigt, an wie vielen Standorten das Element liegt und ob 3-2-1 erfüllt ist. Siehe Ablage pro Element.
• Ablage-Vorgaben. Eine Zeile pro Bereich legt fest, wohin neue Elemente geschrieben werden und auf welche Ziele Elemente ohne eigene Wahl kopiert werden. Das Ändern verschiebt keine Backups und nennt vorher, welche Ziele Elemente gewinnen oder verlieren.
• Manuelle Backup-Reihenfolge. Lege die exakte Reihenfolge, in der deine Container gesichert werden, im Panel backup-order auf der Container-Seite fest. Geplante und Mehrfachauswahl-Läufe folgen ihr; jeder Container, den du unsortiert lässt, behält das bisherige Verhalten (zuerst am höchsten überfällig), und ein einzelnes Container-Backup bleibt unverändert.
• Konfigurierbare Aufbewahrung: keep-last / täglich / wöchentlich / monatlich / jährlich, nach jedem Backup automatisch gekürzt, pro Quelle gesetzt (lokal und Off-site beide unter Einstellungen, Aufbewahrung, sodass du Off-site-Kopien länger als Archiv behalten kannst). Jede Quelle kann außerdem eigene Regeln haben, lokal und Off-site (Aufbewahrung je Quelle), etwa 7 tägliche Backups für Container, die sich täglich ändern, und weniger für VMs, die sich selten ändern.
• Kompression pro Repository: Aus, Automatisch (restics Standard) oder Maximum, einstellbar unter Einstellungen, Speicher für jeden Backup-Pfad und jedes benannte Repository und unter Einstellungen, Off-site für jedes Off-site-Ziel. Backups, Off-site-Kopien und das Aufräumen schreiben damit, und das Recovery-Kit nennt sie, damit ein reines restic genauso weiterschreiben kann.
• Planung pro Bereich (täglich / wöchentlich inklusive mehrtägiger Sätze / alle N Tage / rohes cron), alle an einem Ort unter Einstellungen, Zeitpläne bearbeitet. Ein einzelner Container, eine VM, ein Ordner-Set oder ein ZFS-Element kann einen eigenen Rhythmus haben, und Alle N Tage gibt es auch für die Wiederherstellungsübung, den Manipulationstest und den Wochenbericht.
• Warten, bis die App ruht. Ein Container kann sein geplantes Backup warten lassen, solange seine App beschäftigt ist, höchstens so viele Stunden wie eingestellt, und es starten, sobald die App ruht. Ein Mediaserver ruht, wenn er nicht streamt, jeder andere Container, wenn CPU und Verkehr ein paar Minuten unter den Grenzen unter Einstellungen, Zeitpläne bleiben (im Host-Netz zählt nur die CPU). Das wartende Backup steht mit Grund und Frist im Aktivitätsprotokoll und auf dem Container. Es hält keine Sperre, die anderen Container laufen also weiter. Manuelle Backups warten nie. Die Mitglieder eines Compose-Stacks, die im selben Lauf dran sind, warten gemeinsam, und ein Warten läuft nach einem Neustart mit seiner Frist weiter. Schaltest du die Container aus, fallen alle wartenden Backups weg, schaltest du ihren Zeitplan aus, die, die seine Läufe zurückgehalten haben. Weniger Stunden verkürzen auch eine Wartezeit, die schon läuft.
• Off-site-Bandbreitenlimits. Begrenze die restic-Upload-/Download-Rate, damit die Replikation dein WAN nicht auslastet.
• Streaming zuerst. Solange ein Mediaserver wie Plex, Jellyfin oder Emby streamt, laden Off-site-Kopien mit einer niedrigeren Grenze hoch und kehren ein paar Minuten nach dem Stream zur normalen zurück. BombVault liest den ausgehenden Verkehr der Mediaserver aus Docker. REST, S3, B2, Azure, Google Cloud, Swift und rclone über HTTP werden mitten in der Kopie langsamer; SFTP sowie lokale und eingehängte Ordner bekommen die niedrigere Grenze beim nächsten Kopierschritt. Ein Mediaserver im Host-Netz lässt sich nicht messen. Unter Einstellungen, Off-site.
• Kalt- und Archiv-Speicherklasse (S3). Für ein natives S3-Off-site-Repo kannst du die Speicherklasse wählen, beschränkt auf wiederherstellungslesbare Stufen (Standard, Standard-IA, One Zone-IA, Intelligent-Tiering, Glacier Instant Retrieval), sodass Archivtarife nie stillschweigend eine Wiederherstellung zerbrechen. Die Deep-Archive-Stufen, die zuerst ein asynchrones Auftauen benötigen (Glacier Flexible, Deep Archive), sind bewusst ausgelassen. Nur native S3-Backends; rclone-Remotes setzen ihre Klasse in der rclone-Konfiguration.
• Backup-Ordner bleiben off-box kopierbar. Nach jedem Backup lockert BombVault den lokalen Repo-Baum auf Verzeichnisse 0755 / Dateien 0644 (Repos sind verschlüsselt, es wird also nichts offengelegt), damit ein Nicht-Root-Sync-Benutzer über SMB nicht ausgesperrt wird. Recovery-Definitionen liegen in jedem Repo, sodass ein kopierter Repo-Ordner vollständig eigenständig ist.

Einblick, Prüfung & Überwachung

• Pausieren auf der Karte. Jede Container-, VM- und Ordner-Set-Karte hat Zeitplan pausieren, das den Eintrag aus dem Zeitplan und aus dem Gesamt-Backup nimmt, und Zeitplan fortsetzen, das ihn zurückholt. Der Knopf setzt denselben Schalter wie Im Zeitplan einschließen, die beiden stimmen also immer überein. Ein pausierter Eintrag trägt das graue Abzeichen Zeitplan pausiert, und Jetzt sichern geht weiterhin.
• Schutzstatus (RPO). Das Dashboard zeigt pro Bereich eine grün / gelb / rot-Anzeige, die das letzte erfolgreiche Backup mit seinem Zeitplan vergleicht, sodass ein überfälliges Backup rot wird, statt sich in einem Log zu verstecken.
• Backup-Gesundheits-Heatmap. Ein Kalender im Stil der GitHub-Contributions mit Backup-Ergebnissen pro Tag und Bereich, mit einem Umschalter für Container / VMs / Flash / Selbst-Backup / Ordner.
• Laufzeiten überall. Jeder Eintrag der Laufhistorie liest Start, Ende (Dauer), und jeder Container und jede VM trägt auf ihrer Seite eine eigene Liste Letzte Läufe.
• Ein Dashboard, das du umordnen kannst. Schalte den Anpassungsmodus ein, um Karten in deine Reihenfolge zu ziehen und die auszublenden, die du nicht brauchst. Das Layout wird pro Browser gespeichert.
• Repository-Größe & Dedup-Trend. Aktuelle Repo-Größe, Deduplizierungsverhältnis und Snapshot-Anzahl pro Bereich, mit einer Sparkline des Speicherwachstums.
• Wiederherstellungs-Prüfübungen. BombVault beweist regelmäßig, dass deine Backups wiederherstellbar sind (restic check --read-data-subset, begrenzt), und zeigt pro Bereich ein Abzeichen Wiederherstellbar verifiziert.
• Wiederherstellungsprüfung nach der ersten Sicherung. Ist die erste Sicherung eines Elements fertig, stellt BombVault eine Stichprobe davon (bis zu 100 Dateien und 256 MiB) in einem temporären Ordner unter dem Restore-Ordner wieder her, lässt restic jede Datei gegen ihre Prüfsummen zurücklesen und vergleicht die Größen mit der Sicherung. Bei einer Datei, die für die Stichprobe zu groß ist, etwa einer VM-Disk, werden stattdessen die ersten 64 MiB zurückgelesen. Die Karte des Elements zeigt das Ergebnis, ein Fehlschlag kommt als Benachrichtigung, und Wiederherstellung prüfen führt dieselbe Prüfung jederzeit für die neueste Sicherung aus. Spätere Sicherungen wiederholen sie nicht.
• Start-Test. Stimmende Bytes zeigen nicht, dass die App wieder hochkommt. Start-Test auf einer Container-Karte stellt die neueste Sicherung als isolierte Kopie wieder her und startet sie: ein Name, der mit bombvault-test- beginnt, ein eigenes internes Docker-Netz ohne veröffentlichte Ports und ohne Weg ins LAN, 1 CPU und 2 GiB Speicher, die Daten in einem temporären Ordner unter dem Restore-Ordner. Bestanden ist der Test, wenn der Healthcheck des Containers gesund meldet, ohne Healthcheck, wenn sein erster freigegebener Port aus diesem Netz antwortet, und ohne beides, wenn er weiterläuft. Der Original-Container wird nie gestoppt oder verändert, Kopie, Netz und Daten werden danach entfernt, auch wenn BombVault mitten im Test neu startet. Container im Host-Netz, privilegierte, solche mit Geräten und solche, die einen anderen Container brauchen, werden als nicht testbar angezeigt. Mit Start-Test bei den geplanten Wiederherstellungsprüfungen wird pro Lauf ein Container getestet, der am längsten nicht getestete zuerst. Das Ergebnis steht auf der Karte und im Dashboard. Die Kopie trägt keine Labels des Originals und läuft ohne die Capabilities, Sicherheitsoptionen, Sysctls und den Cgroup-Parent, die das Original zusätzlich hat. Ein Container, der sie braucht, fällt durch, und das Ergebnis nennt, ohne was die Kopie lief.
• Selbstheilende Abläufe. Ein nachweislich verwaister restic-Lock (durch einen Neustart mitten im Betrieb hinterlassen) wird automatisch zwangsweise gelöst und einmal wiederholt. Die Aufbewahrung ist identitätsstabil (pro Element gekürzt, immun gegen Pfad- oder Host-Änderungen), und ein Aufbewahrungsfehler sendet eine Benachrichtigung.
• Warnungen, die der Ordner-Scan nicht sieht. Der Ausschluss-Assistent beantwortet eine Größenfrage. Einige der teuersten Backup-Fehler sind keine Größenfragen, deshalb bringt er auch app-spezifische Hinweise dazu mit, wie eine Anwendung ihre Daten ablegt. Der Hinweis, für den es ihn gibt: Immich hält Alben, Gesichter und Aufnahmedaten jedes Fotos in einer PostgreSQL-Datenbank, die in einem eigenen Container läuft. Ein Backup des Immich-Containers auf Dateiebene stellt also die Bilder ohne all das wieder her, und die Wiederherstellung sieht aus, als hätte sie geklappt. Die Warnung erscheint unabhängig davon, ob ein Ausschluss angeboten wird, auch bei einem Container, bei dem nichts zum Scannen ausgewählt ist, weil der Hinweis so oder so stimmt.
• Nicht gesichert (Abdeckung). Eine Dashboard-Karte, die alles auf dem Server nennt, was keine automatische Sicherung abdeckt, jeweils mit dem Grund: nie zu BombVault hinzugefügt, vorhanden, aber nicht im Zeitplan enthalten, eigener Zeitplan auf aus gestellt oder nirgends ein Zeitplan eingeschaltet. Die Schutzanzeige darüber beantwortet eine andere Frage, nämlich ob die Backups, die geplant sind, pünktlich gelaufen sind, und den Container, den nie jemand eingerichtet hat, sieht sie nicht: Der fehlt in jeder Liste und in jedem Fehler, also wird für ihn nichts gelb. Container werden aus der laufenden Docker-Liste gelesen statt aus BombVaults eigenen Zeilen, denn ein Element ohne Zeile ist genau das, das genannt werden muss. Ein Backup-Typ, den du abgeschaltet hast, fällt ganz aus der Zählung, weil das deine Entscheidung war.
• Vorschau der Aufbewahrung. Das Panel neben den Aufbewahrungseinstellungen zeigt, was der nächste Lauf löschen wird, bevor es passiert: pro Repository und pro Element, mit den Wiederherstellungspunkten beim Namen. Es nimmt keinen Repository-Lock und ändert nichts, deshalb antwortet es auch, während ein Backup läuft. Ist die Aufbewahrung ausgeschaltet, sagt es das, statt eine leere Liste zu zeigen, ein Append-only-Repository ist als solches gekennzeichnet (dort läuft die Aufbewahrung überhaupt nie), und ein Repository, das nicht erreichbar war, wird genannt, statt stillschweigend zu fehlen. Zu finden unter Einstellungen, Aufbewahrung, für die lokale und die Off-site-Richtlinie, jede mit ihrer eigenen Vorschau.
• Anomalien. Jedes Backup eines Containers, einer VM, eines Ordner-Sets, eines Datenbank-Dumps, des Flash-Laufwerks und des Selbst-Backups wird mit dem eigenen Verlauf dieses Elements verglichen. Geprüft werden die neuen Daten eines Laufs, gemessen an den größten üblichen Mengen der letzten Backups und an der üblichen Rate pro Stunde; ein Backup, das die meisten Daten neu gespeichert hat, auch umbenannte und neu geschriebene Dateien; Quellgröße und Dateianzahl, die restic für jedes Element und jeden Datenbank-Dump meldet; restics eigene Backup-Dauer; Serien von Fehlschlägen und gelegentliche Fehlschläge; Wiederherstellungsprüfungen, die nicht mehr bestehen; und der freie Platz lokaler, SFTP- und rclone-Repositories, hochgerechnet aus dem Wachstum des Repositorys. Ein Element lernt aus seinen ersten 10 Backups, eine fast leere Quelle, ein Neuschreiben der meisten Daten und Fehlschläge werden von Anfang an geprüft. Beim Update wird der Verlauf einmal aus den Snapshot-Zusammenfassungen gelesen, die restic 0.17 speichert, deshalb fängt eine bestehende Installation nicht bei null an. Die Empfindlichkeit (Streng, Ausgewogen, Nachsichtig) und der niedrigste Schweregrad, der eine Benachrichtigung schickt, werden global unter Einstellungen, Integrität eingestellt und lassen sich je Element ändern. Warnungen schließen sich selbst, sobald die Ursache weg ist; kritische Funde zu verlorenen Daten und einer volllaufenden Platte bleiben, bis du sie quittierst, und ein quittierter Fund wird erst wieder gemeldet, nachdem seine Ursache einmal verschwunden war. Als erwartet markieren macht ein neues Niveau nach 10 Backups zum Normalfall, schaltet die Prüfung auf eine fast leere Quelle aber nie ab, und nach einer geänderten Auswahl beginnt der Verlauf des Elements von selbst neu. Solange eine Quelle fast leer ist, stark geschrumpft ist oder ein Backup die meisten Daten neu gespeichert hat, behält die Aufbewahrung die alten Backups dieses Elements, bis du den Fund quittierst oder als erwartet markierst, und der Fund verlinkt auf das letzte gute Backup. Eine Benachrichtigung geht einmal pro Episode raus, und Fehlschläge und Wiederherstellungsprüfungen, die schon selbst benachrichtigen, werden nicht doppelt gemeldet. Was es nicht kann: S3-, B2- und REST-Repositories haben keine Angabe zum freien Platz, auf dem Unraid-User-Share ist der freie Platz der des ganzen Arrays, und Backups aus der Zeit vor restic 0.17 haben keinen Größenverlauf. Auch ZFS-Elemente werden geprüft, Dataset für Dataset: Jedes Dataset eines Baums hat seinen eigenen Verlauf, eines, das geleert wurde oder nicht mehr gelesen werden konnte, zählt als Datenverlust, und nur die alten Backups dieses Datasets werden behalten. Wie ein ZFS-Element Dataset für Dataset überwacht wird, steht unter ZFS-Datasets, und ein Assistent kann die offenen Anomalien über den MCP-Server lesen. Ein Fund zur Größe oder Dateizahl einer Quelle wird auf das erste Backup datiert, in dem er auftrat, und Mit dem Backup davor vergleichen listet die Ordner, in denen Dateien weggefallen, hinzugekommen oder geändert sind, mit einem Hinweis, wenn fast alles in einem Suchindex, einem Cache oder Vorschaubildern liegt, die die App selbst neu aufbaut.
• Empfohlene Ausschlüsse je App. Für bekannte Images (Plex, Jellyfin, Emby, Sonarr, Radarr, Lidarr, Readarr, Prowlarr, Immich, Nextcloud, PhotoPrism und Tautulli, von linuxserver, hotio, binhex oder dem offiziellen Herausgeber) bietet der Ausschluss-Assistent die Ordner an, die die App von selbst wieder füllt: Caches, Logs, Vorschaubilder und Poster. Jeder Eintrag sagt, was er enthält, jeder lässt sich abschalten, und ausgeschlossen wird erst, wenn du Auswahl ausschließen drückst.
• Support-Paket. Ein geschwärztes ZIP für einen Fehlerbericht, mit einem Klick: die Prüfung der Host-Integration, deine Konfiguration ohne jedes Geheimnis, die letzten Läufe, was als Nächstes geplant ist, und das aktuelle Log. Dazu kommt, wie der letzte Dump jeder Datenbank gelaufen ist, die ZFS-Elemente mit den Mounts, die der Container sieht, die offenen Anomalien und wie viele MCP-Schlüssel es gibt (nie ihre Namen). Passwörter, Tokens, die rclone-Konfiguration, Zugangsdaten für Benachrichtigungen und jedes in einem Repository-Ort eingebettete Passwort werden entfernt, und das Paket sagt das in seinem eigenen Manifest, denn eine Support-Datei darf nie mit einem Konfigurations-Backup verwechselt werden. Aus demselben Grund wie das Recovery-Kit verlangt es ein Anmeldepasswort. Das enthaltene Log ist die Ausgabe dieses Containers seit seinem letzten Start; bei einem Absturz, der den Container neu gestartet hat, bleibt docker logs die Stelle zum Nachsehen.
• Wiederherstellungspaket für den Verschlüsselungsschlüssel. Ein-Klick-Download des Master-Keys, des abgeleiteten restic-Passworts und der genauen Repo-Orte und -Befehle, sodass du ohne laufendes BombVault wiederherstellen kannst. Siehe Off-site & Wiederherstellung.
• Exportiere und importiere deine Einstellungen. Eine Karte Einstellungen exportieren / importieren auf der Seite Einstellungen, System schreibt deine gesamte Konfiguration (Bereichseinstellungen, Off-site-Ziele, Zeitpläne, Aufbewahrung, Benachrichtigungen) in eine portable JSON-Datei, sodass ein Umzug auf eine neue Box oder das Klonen eines Setups nicht bedeutet, alles von Hand neu einzugeben. Du wählst, ob die Off-site- und Benachrichtigungs-Zugangsdaten enthalten sein sollen; mit ihnen ist die Datei so sensibel wie dein Recovery-Kit. Der Import zeigt eine Vorschau und fragt nach Bestätigung und rührt niemals deine Backup-Daten oder -Historie an.
• Benachrichtigungen. Webhook (Discord / Slack / Gotify / ntfy), Matrix, Healthchecks.io, E-Mail (SMTP), ein selbstgehosteter Apprise-API-Server und Unraids natives Benachrichtigungssystem. Richtlinie pro Backup: nie / bei Fehler / immer. Ein geplanter Lauf mit vielen Elementen kann eine einzelne Zusammenfassung N von M erfolgreich senden. Healthchecks erhält den vollen Lebenszyklus (/start, dann Erfolg oder /fail), sobald eine URL gesetzt ist.
• Wochenbericht. Einmal pro Woche eine Nachricht über dieselben Kanäle: die Zahl der Läufe, wie viele neue Backup-Daten dazugekommen sind, ob Off-site aktuell ist, und die häufigsten Fehlschläge. Standardmäßig aus, mit eigenem Rhythmus unter Einstellungen, Benachrichtigungen, damit auch eine ruhige Woche als solche gemeldet wird.
• Prometheus /metrics. Opt-in (standardmäßig aus, optionaler Bearer-Token) für Grafana oder Uptime Kuma. Stellt Backup-Status, -Größen und -Zeitstempel bereit, ohne Geheimnisse oder Pfade in den Labels.
• HTTP-API, Home Assistant und mDNS. Skripte und Dashboards bekommen eine API unter /api/v1 mit benannten Tokens, nur lesend oder mit der Erlaubnis, Backups zu starten. Home Assistant findet BombVault über MQTT Discovery, als Gerät mit Sensoren und, wenn du es erlaubst, einem Backup-Knopf pro Bereich. Außerdem meldet sich BombVault im Netzwerk als bombvault.local. Siehe API und Integrationen.
• Freier Platz und Wochen bis voll. Lokale Repositories, SFTP-Repositories und SMB- oder WebDAV-Ziele, die ihn melden, zeigen ihren freien Platz und wie viele Wochen beim jetzigen Wachstum noch bleiben. S3-, B2- und REST-Repositories zeigen "Freier Platz unbekannt", weil diese Backends ihn nicht melden.
• Größe nach Ordner. Im Bereich Backups eines Containers, einer VM oder eines Ordner-Sets zeigt Größe nach Ordner, welche Ordner und Dateien im neuesten Backup Platz belegen und wie viel davon das letzte Backup neu oder geändert mitgebracht hat, Ebene für Ebene. BombVault liest das aus dem Index des Repositorys, ohne die Dateien zu lesen, und hält es nach jedem Backup aktuell, sobald du es einmal geöffnet hast.
• Warum ein Backup langsam war. Während ein Backup läuft, sieht BombVault nach, wie ausgelastet CPU, Datenträger und Netz sind. Dauert ein Backup deutlich länger als sonst und war eine Sache klar am Anschlag, steht das beim Lauf, zum Beispiel „Der Ziel-Datenträger disk1 war zu 98 % ausgelastet“ oder „BombVault hat 100 % der CPU-Grenze seines Containers genutzt“. Sonst steht dort nichts.
• Seit dem letzten Backup geändert. Ein Container, der seit seinem letzten Backup mit anderem Image, anderen Ports, Variablen oder Volumes neu erstellt wurde, bekommt ein Zeichen neben seinem Namen. Sein (i) nennt, was sich geändert hat, Variablen nur mit Namen. Es ist nur ein Hinweis und verschwindet mit dem nächsten Backup.

Ransomware-Schutz

• Unveränderliches (Append-only) Off-site. Markiere ein Off-site-Repo als Append-only, sodass Ransomware oder ein kompromittierter Host deine Backups nicht löschen oder überschreiben kann. Die Gegenseite (ein restic/rest-server im --append-only-Modus) erzwingt es; BombVault verifiziert es nur und zeigt niemals grün allein auf eine Konfigurationsbehauptung hin.
• Manipulationstest. BombVault beweist die Append-only-Garantie regelmäßig, indem es tatsächlich einen Löschversuch gegen das Off-site-Repo unternimmt (gezielt auf ein nicht existierendes Objekt): verweigert bedeutet geschützt, akzeptiert bedeutet nicht geschützt. Ein unschlüssiges Ergebnis kippt das gespeicherte Urteil nie.
• Geführte Off-site-Einrichtung. Ein Assistent führt dich von der Backend-Wahl über ein einsatzbereites rest-server-Deploy-Snippet, einen Verbindungstest, den Unveränderlichkeits-Schalter bis zu einer Aufbewahrungsstrategie.
• DR-Übungen (Off-site). Stelle ein echtes Ziel aus dem Off-site-Repo in eine Wegwerf-Sandbox wieder her, prüfe es Datei für Datei und Byte für Byte und räume dann auf. Siehe Off-site & Wiederherstellung.
• Ransomware-Schutz-Scorecard. Eine Dashboard-Karte mit einer grün / gelb / rot-Haltung pro Bereich und einer altersgestempelten Checkliste; jede rote Zeile verlinkt tief zur Behebung. Sie wird nur bei verifizierten Fakten grün.
• Wachstumsbudget-Alarm. Für ein unveränderliches Off-site (bei dem alte Snapshots bewusst nie gekürzt werden) ein Größenbudget setzen und alarmiert werden, bevor es außer Kontrolle gerät.
• Kopplung per Phrase. Instanzen bilden mit zwölf Wörtern eine Gruppe: Phrase auf einer erstellen, auf der nächsten eintippen. Mitglieder im selben Netzwerk sprechen direkt miteinander, die anderen über ein Relay (das Projekt-Relay, ein eigenes oder keins), und jeder Aufruf zwischen ihnen ist Ende-zu-Ende verschlüsselt. Über die Gruppe laufen die Scorecards auf der Instanzen-Seite, Mesh-Off-site-Angebote und was Empfänger und Holen brauchen, nie Backup-Daten und nie der APP_KEY. Siehe Off-site & Wiederherstellung.
• Instanzen-Seite. Schalte Instanzen in den Einstellungen ein, dann bekommst du eine Seite mit einer Karte für jede Instanz deiner Gruppe, diese eingeschlossen: ihre Adresse, ob sie verbunden ist, und den Schutzstatus jedes Bereichs mit seinem letzten Backup, im selben Rot, Gelb und Grün wie auf dem lokalen Dashboard. Jetzt prüfen bittet ein Mitglied, das Repository eines Bereichs zu prüfen. Nichts auf dieser Seite kann auf einer anderen Box ein Backup starten, etwas wiederherstellen oder löschen.
• Mesh-Off-site. Ein Mitglied kann einem anderen Mitglied über die Gruppe seinen eigenen Off-site-Speicher anbieten. Der Admin auf der anderen Seite sieht das Angebot auf der Instanzen-Seite und nimmt es an oder lehnt es ab; beim Annehmen entstehen ein gewöhnlicher Zugangsdaten-Satz und ein Off-site-Ziel. Auf diesem Weg reisen nur Verbindungsdaten, nie Backup-Daten.
• Empfänger-Dashboard (empfangende Seite). Auf der Box, die unveränderliche Off-site-Kopien von einem anderen BombVault empfängt, schalte den Empfänger-Schalter (Einstellungen) ein, um einen Empfänger-Tab freizulegen. Registriere ein empfangenes Repository schreibgeschützt (geöffnet mit dem Restic-Passwort der sendenden Instanz, das über die Kopplungsgruppe kommt), um seinen Snapshot-Bestand gruppiert nach Quelle zu sehen, wann jede Quelle zuletzt eingetroffen ist, und führe eine unabhängige restic check auf der empfangenden Hardware aus. Es alarmiert dich, wenn eine Quelle innerhalb eines von dir gesetzten Fensters aufhört zu senden (ein Totmannschalter) oder wenn eine Integritätsprüfung fehlschlägt. Strikt schreibgeschützt, sodass es niemals in das empfangene Repository schreibt, und standardmäßig aus. Siehe Off-site & Wiederherstellung.
• Von einer anderen Instanz holen (abholende Seite). Das Spiegelbild der Off-site-Replikation: Statt dass diese Box ihre Snapshots hinausschiebt, holt sie die einer anderen Instanz herein. Schalte den Holen-Schalter (Einstellungen) ein, um den Reiter Holen der Seite Instanzen freizulegen, wähle die andere Instanz aus deiner Kopplungsgruppe und ihren Repository-Ort, dann, welche Art von Backup darin liegt und wie oft geholt wird. Ihr restic-Passwort kommt über die Gruppe, nie ihr APP_KEY. Die Gegenseite richtet nichts weiter ein und muss nicht laufen. Das Quell-Repository wird nur gelesen: Es wird geöffnet, um das Passwort zu prüfen, aufgelistet und als Quelle der Kopie genannt, aber nie initialisiert, entsperrt, gekürzt oder beschrieben. Jede Seite behält ihre eigenen Zugangsdaten, und eine rclone:-Quelle wird abgelehnt, weil rclone sie mit den Remotes dieser Instanz erreichen würde. Siehe Off-site & Wiederherstellung.

Schlichte Exporte

• Container-Schlichtexport. Ein Export (Plain-tar)-Button pro Container schreibt eine durchsuchbare, werkzeugfreie Kopie neben das Repo: <name>.tar.gz der Backup-Ordner plus das Unraid-<name>.xml-Template. restic bleibt die Engine; dies ist eine zusätzliche Bequemlichkeitskopie.
• VM-Schlichtexport. VMs haben denselben Export (schlichtes tar): <name>.tar.gz der Datenträger-Image(s) plus <name>.xml, wiederherstellbar mit virsh define plus dem Datenträger, ohne BombVault oder restic.
• Die schlichten Exporte verschlüsseln (age). Die Exporte liegen außerhalb von restic, sind also standardmäßig Klartext. Aktiviere die age-Verschlüsselung unter Einstellungen und füge einen oder mehrere Empfänger hinzu (einen age-Public-Key oder einen SSH-Public-Key). Jeder Export (Container- und VM-.tar.gz, ihre .xml-Beilagen und das Flash-ZIP) wird dann für diese Empfänger versiegelt, und du entschlüsselst ihn später off-box mit dem passenden privaten Schlüssel. Als Sicherheitsregel gilt: mit aktivierter Verschlüsselung und ohne gültigen Empfänger schlägt ein Export mit einem klaren Fehler fehl, statt jemals Klartext zu schreiben.
• Auch das Recovery-Kit wird versiegelt. Mit derselben Einstellung wird das Kit als bombvault-recovery-kit.md.age heruntergeladen. Es ist ASCII-armored statt binär und bleibt damit lesbarer Klartext: Du kannst es weiterhin in einen Passwortmanager einfügen oder ausdrucken, und genau dafür ist das Kit da. Es gilt dieselbe Sicherheitsregel: Mit eingeschalteter Verschlüsselung und ohne brauchbaren Empfänger wird der Download verweigert, statt den Master-Key ersatzweise im Klartext herauszugeben. Eins musst du beim Einschalten richtig machen: Zum Öffnen des Kits brauchst du deinen privaten age-Schlüssel, bewahre ihn also an einem Ort auf, der nicht vom Kit selbst abhängt.

KI-Assistenten (MCP)

BombVault bringt einen MCP-Server mit, über den ein Assistent wie Claude Code oder Claude Desktop Sicherungsstand, Abdeckung, Laufverlauf, Wiederherstellungspunkte und die laufende Aktivität lesen kann. Mit einem Schlüssel, der es erlaubt, kann er außerdem ein Backup eines Elements, einer Domäne oder von allem starten und die Backups abbrechen, die er selbst gestartet hat. Wiederherstellungen, Löschungen, Prune und Einstellungen bleiben in der Web-Oberfläche. Jeder Client bekommt seinen eigenen Schlüssel unter Einstellungen, Anbindungen, MCP-Server; ein Schlüssel wird einmal angezeigt, nur als Fingerabdruck gespeichert und lässt sich jederzeit umbenennen, ersetzen oder widerrufen. Starts sind pro Stunde und pro Element begrenzt, und ein Aufbewahrungsschutz verhindert, dass Backups eines Assistenten deine eigenen Wiederherstellungspunkte aus einer Regel "die letzten N behalten" verdrängen. Jeder Lauf, den ein Assistent startet, ist mit "über MCP" und dem Namen des Schlüssels markiert. Siehe MCP-Server. Datenbank-Dumps und ZFS-Datasets gehören zu den Elementen und Wiederherstellungspunkten, die er liest, und er kann die Anomalien auflisten, die BombVault bemerkt hat.

Apps und Begleiter

• Android-App. Jeder Server deiner Gruppe auf deinem Handy, mit dem Aktivitätsprotokoll aller Server auf einem Bildschirm. Die App koppelt sich per QR-Code mit deiner Gruppe und öffnet jeden Server bereits angemeldet. Siehe Android-App.
• Empfangsserver. Die Box, die Off-site-Kopien empfängt, startet mit einem Klick einen rest-server im Append-only-Modus und bietet ihn den anderen Instanzen deiner Gruppe an, jeder mit eigenem Login. Siehe Empfangsserver.
• Einstellungen, Apps. Eine Seite, die mit der Android-App beginnt, mit ihrer APK für das Release, das auf dem Server läuft, und einem QR-Code dazu, danach eine Karte für jeden Begleiter. Die Karte von ParleyPort bietet sein Unraid-Template an, kopiert den Docker-Befehl, der ihn startet, und führt zu seinem Repository und zu den Relay-Einstellungen unter Kopplung. Die Karte des BombVault Widget bietet sein Template und sein Repository an und installiert oder entfernt das Plugin über die Host-SSH-Verbindung.
• BombVault Widget. Eine Kachel auf dem Unraid-Dashboard mit BombVaults Aktivitätsprotokoll und dem nächsten geplanten Lauf. Ohne Host-SSH-Verbindung gibt dir die Karte die .plg-Adresse zum Installieren unter Plugins, Install Plugin, und das Plugin lässt sich dort entfernen wie jedes andere.
• Einbettbares Aktivitätsprotokoll. Erzeuge unter Einstellungen, Anbindungen ein Nur-Lese-Token, dann bekommst du eine Adresse für jedes Dashboard, das ein Iframe anzeigen kann, etwa Homepage, Organizr oder Heimdall: eine kleine Seite, die nur das laufende Aktivitätsprotokoll zeigt. Das Token gewährt dieses Protokoll und sonst nichts, und Deaktivieren widerruft es sofort. Die eingebettete Seite gibt es nur auf Englisch.

Sonstiges

• Ein laufendes Backup stoppen. Jede Karte, die ein Backup starten kann, hat neben ihrem Fortschrittsbalken einen Knopf Backup abbrechen, solange der Lauf aktiv ist. Der Lauf wird als abgebrochen erfasst, nicht als fehlgeschlagen. Das Stoppen ist sicher, weil restic seinen Snapshot zuletzt schreibt: Ein abgebrochener Lauf hinterlässt unreferenzierte Daten und keinen Snapshot.
• Viele auf einmal sichern. Container per Mehrfachauswahl markieren und Ausgewählte sichern klicken. Der Stapel läuft serverseitig, sodass er weiterläuft, selbst wenn du den Tab schließt oder die Verbindung verlierst. BombVault sichert (und stoppt somit) niemals seinen eigenen Container.
• Snapshot-Browser mit einer Liste von Wiederherstellungspunkten, Löschen pro Snapshot und einem einklappbaren Ordnerbaum für die Wiederherstellung auf Dateiebene.
• Repository-Wartung pro Bereich: Prüfen (restic check), Entsperren (einen veralteten Lock lösen) und Kürzen (wendet bei gesetzter Richtlinie die Aufbewahrungsrichtlinie auf Abruf an, sonst eine schlichte Platzrückgewinnung).
• Fortschritt für Prüfen, Wiederherstellungsprüfungen und Aufräumen. Während eines davon läuft, zeigen das Aktivitätsprotokoll und die Integritätskarte, wie weit restic gezählt hat, etwa 12 von 47 Packs, und sobald genug da ist für eine Schätzung, die verbleibende Zeit dieses Schritts. restic zählt hier Packs, Snapshots und Indexdateien, keine Bytes, also zeigt der Balken genau das; vor der ersten Zählung läuft er ohne Zahl.
• Automatische Datenbank-Dumps. Erkannte PostgreSQL-, MySQL- und MariaDB-Container (die offiziellen Images, PostGIS, TimescaleDB, pgvector, pgautoupgrade, Immichs Datenbank-Images, linuxserver, yobasystems und jc21 MariaDB sowie Oracles mysql-server) werden vor jedem Backup aus dem laufenden Server gedumpt. Container, die nur wie eine Datenbank aussehen, bekommen dieselbe Option auf ihrer Karte, abgeschaltet, bis du dich dafür entscheidest. Der Dump fließt direkt ins Repository und wird dort ein eigener Wiederherstellungspunkt neben dem Datei-Backup; auf eine Platte geschrieben wird er nie. Die Zugangsdaten stammen aus den Variablen des Containers selbst, einschließlich *_FILE-Secrets, und verlassen ihn nicht. Jede Karte zeigt, ob der Datenordner der Datenbank im angehaltenen Zustand gesichert, im laufenden Betrieb kopiert oder gar nicht gesichert wird. Ein fehlgeschlagener Dump lässt das Backup nicht scheitern: er erscheint als fehlgeschlagener Lauf mit seinem Grund und einem Hinweis zur Behebung und löst eine Benachrichtigung aus. Dumps werden nie von selbst zurückgespielt. Lade einen herunter (roh oder komprimiert), speichere ihn in einen Ordner, importiere ihn mit einem Klick in eine frisch gestartete Datenbank, oder hole ihn dir mit der restic-CLI. Abschalten kannst du ihn pro Container, über das Label bombvault.dbdump=false oder für alle Container in den Einstellungen. Die Anomalie-Erkennung beobachtet auch die Größe jedes Dumps, und ein Assistent kann die Dumps eines Containers über den MCP-Server auflisten.
• Pre/Post-Backup-Hooks pro Container. Shell-Befehle laufen im Container (zum Beispiel einen Cache schreiben lassen); ein fehlschlagender Pre-Hook bricht das Backup ab. Erkannte Datenbanken werden automatisch gedumpt und brauchen dafür keinen Hook.
• Andere Container während des Backups stoppen, mit gesundheitsgesteuertem Neustart. Benenne abhängige Container (zum Beispiel eine Datenbank), die gestoppt werden, während dieser gesichert wird. Danach bringt BombVault sie in ihrer Compose-depends_on-Reihenfolge zurück und wartet standardmäßig, bis jeder als gesund gemeldet wird (oder als laufend, wenn er keinen Healthcheck hat), bevor die davon abhängigen Container gestartet werden, sodass eine Abhängigkeit wie Pi-hole, eine Datenbank oder ein VPN-Gateway tatsächlich bereit ist, bevor die Dienste starten, die sie brauchen, statt dass diese zu einem connection refused zurückkehren. Das Warten ist durch ein Timeout pro Container begrenzt (standardmäßig 120 Sekunden), sodass ein langsamer oder nie gesunder Container den Lauf nie aufhängen kann; sowohl das Warten als auch das Timeout liegen unter Einstellungen, Container (schalte das Warten aus für den vorherigen Alle-auf-einmal-Neustart). Derselbe geordnete, gesundheitsgesteuerte Neustart umschließt auch das Image-Update nach dem Backup, sodass an einem Tag, an dem ein Update eintrifft, die Abhängigen durch die Neuerstellung heruntergehalten und erst gesundheitsgesteuert zurückgebracht werden, sobald es erledigt ist.
• Ausschlussmuster pro Container. Liste Unterverzeichnisse auf, die innerhalb eines gesicherten Volumes übersprungen werden sollen, eines pro Zeile. Gib die Pfade so ein, wie du sie im Container siehst; eine Live-Vorschau zeigt, worauf jede Zeile aufgelöst wird, und warnt, wenn eine Zeile nichts ausschließen würde.
• Update nach erfolgreichem Backup (erweitert, standardmäßig aus). Aktiviere dies bei einem Container, und BombVault zieht das neueste Image und erstellt ihn neu, aber nur, wenn es tatsächlich ein neueres Image gibt, sodass zuerst immer ein frischer Wiederherstellungspunkt existiert. Optionale Extras: eine Benachrichtigung pro aktualisiertem Container und Image-Bereinigung (ein von anderen Containern geteiltes Basis-Image wird nie gelöscht). Nach dem Update bittet BombVault Unraid außerdem, den Update-Status genau dieses einen Containers erneut zu prüfen, sodass das veraltete update available-Banner im Docker-Tab sich selbst löscht, statt hängen zu bleiben (Unraid-Updates gehen direkt durch die Docker-API, sodass sein zwischengespeicherter Status und auf manchen Versionen ein zwischengespeicherter Digest sonst das Banner weiter anzeigen würden). Es ist Best-Effort, beeinflusst niemals das Backup, standardmäßig an und hat einen Schalter in den Einstellungen.
• Wiederherstellung in einen alternativen Ordner zum Klonen oder Inspizieren.
• Snapshot-Diff & Tags. Vergleiche zwei Snapshots, um zu sehen, was sich geändert hat, und tagge Snapshots, um sie zu filtern.
• Was ist neu nach einem Update. Release-Notes tauchen einmal pro neuer Version auf, ausgeliefert aus im Binary eingebetteten Notizen, sodass der Dialog offline funktioniert.
• HTTPS von Haus aus (selbstsigniert, oder bring dein eigenes Zertifikat hinter einem Reverse Proxy mit).
• Docker-Healthcheck. Der Container meldet gesund/ungesund aus seinem eigenen /api/health, sodass ein Auto-Heal-Werkzeug ihn neu starten kann, falls sich die Engine je verklemmt.
• Dunkle/helle Oberfläche in 42 Sprachen mit einem Flaggen-Auswähler.
• Einstellungen speichern sich selbst. Leg einen Schalter um oder verlass ein Feld, und die Änderung wird sofort geschrieben, mit einem kurzen Aufblitzen am Bedienelement und einem Wackeln, wenn der Server sie ablehnt. Drei Stellen behalten einen Speichern-Knopf, weil halb fertiges Speichern dort unsicher wäre: das Feld für die rclone-Konfiguration, der Editor für Zugangsdaten-Sätze und das Anmeldepasswort.
• Leise Pop-up-Meldungen. Unter Einstellungen, Allgemein kannst du die routinemäßigen Bestätigungen stummschalten, sodass dich nur noch Fehler unterbrechen. Das gilt pro Browser und lässt die Benachrichtigungskanäle unberührt.
• Aussehen nach deinem Geschmack. Einstellungen, Aussehen legt die Farben fest (eine Akzentfarbe oder den Regenbogen-Modus mit einer Palette aus acht), die Ecken (rund, abgerundet oder eckig) und die Animation (aus, dezent, wild oder Sturm), gespeichert pro Browser. Wenn dein System weniger Bewegung verlangt, hat das immer Vorrang.