Zum Inhalt

Funktionen

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

Backup-Umfang

Was Was gesichert wird
Docker-Container Appdata-Verzeichnis plus die Container-Definition (Image, Umgebungsvariablen, Ports, Labels, Volumes).
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.
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).

Wiederherstellung

  • Ein-Klick-Vollwiederherstellung. Snapshot wählen, auf Wiederherstellen klicken. Fertig.
  • Wiederherstellung von lokal oder Off-site. Jeder Backup-Browser hat einen Schalter Lokal / Off-site, sodass du bei verlorenem oder beschädigtem lokalem Repo direkt aus der Off-site-Replik auflisten und wiederherstellen kannst. Das Löschen erfolgt pro Quelle: Ein Backup zu entfernen betrifft nur die Kopie, die du gerade ansiehst.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 Recovery-Tab 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.

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/CIFS und NFS (Freigabe auf Unraid einhängen und einen Backup-Pfad darauf richten), native restic-Backends ohne rclone (s3:..., rest:http://host:8000/repo, b2:..., 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 und Dateisätze) kann gleichzeitig an mehrere Off-site-Ziele replizieren, nicht nur eines. Füge zusätzliche Ziele im Off-site-Tab 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.
  • 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, nach jedem Backup automatisch gekürzt, pro Quelle gesetzt (lokal neben den Backup-Pfaden, Off-site im Off-site-Tab, sodass du Off-site-Kopien länger als Archiv behalten kannst).
  • 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.
  • Off-site-Bandbreitenlimits. Begrenze die restic-Upload-/Download-Rate, damit die Replikation dein WAN nicht auslastet.
  • 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

  • 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 / Config / Dateien.
  • 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 zuletzt als wiederherstellbar geprüft.
  • 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.
  • 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 und importieren auf der Einstellungsseite 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.
  • 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.

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.
  • 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 Schlüssel der sendenden Instanz), 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.

Schlichte Exporte

  • Container-Schlichtexport. Ein Export-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.

Sonstiges

  • 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).
  • Pre/Post-Backup-Hooks pro Container. Shell-Befehle laufen im Container (zum Beispiel mysqldump in Appdata vor dem Backup); ein fehlschlagender Pre-Hook bricht das Backup ab.
  • 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, Zeitpläne (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 26 Sprachen mit einem Flaggen-Auswähler.