Backup

Sicherungsaufträge mit Zeitplan und Aufbewahrung: rsync, S3 (rclone) und Appdata-Snapshots, Wiederherstellung.

Aufträge

Backup → Neuer Auftrag. Jeder Auftrag hat einen Namen, eine Art, optional einen Zeitplan (stündlich, täglich, wöchentlich, monatlich; Ortszeit des Servers) und eine Aufbewahrung. Unter Verlauf stehen die letzten 50 Läufe mit Ergebnis, übertragener Menge, Dauer und Protokoll; laufende Aufträge zeigen Schritt und Fortschritt und lassen sich abbrechen. Ziel testen prüft Verbindung und Zugangsdaten, ohne Daten zu übertragen.

Art	Was passiert
rsync	Ordner werden per rsync über SSH (Schlüssel von Bunkerbox) oder zu einem rsync-Daemon gespiegelt.
S3 (rclone)	Ordner werden per rclone sync in einen S3-kompatiblen Bucket hochgeladen, optional clientseitig verschlüsselt (rclone crypt).
Appdata-Snapshot	Gewählte Apps und Container/VMs werden angehalten, die Datasets rekursiv per ZFS-Snapshot gesichert und alles wieder gestartet; optional wird der Snapshot danach per rsync oder S3 übertragen.

Quellen von rsync- und S3-Aufträgen müssen in einem eingehängten Dataset, unter /appdata oder unter /mnt/remotes liegen. Jeder Ordner landet unter seinem Namen im Ziel (/tank/documents → <ziel>/documents), deshalb müssen die Namen eindeutig sein.

Ein fehlgeschlagener Lauf löst die Benachrichtigung „Backup fehlgeschlagen“ aus (siehe Benachrichtigungen). Solange ein Auftrag läuft, wartet ein Update. Läufe, die durch einen Neustart von Bunkerbox unterbrochen wurden, werden als fehlgeschlagen markiert; von ihnen angehaltene Apps und Instanzen werden wieder gestartet.

rsync-Ziele

• SSH: Unter Backup → SSH-Schlüssel erzeugt Bunkerbox einmalig einen ed25519-Schlüssel (/appdata/bunkerbox/data/backup/ssh/, nur root). Den öffentlichen Schlüssel auf dem Zielserver in ~/.ssh/authorized_keys des Zielbenutzers eintragen. Der Host-Schlüssel des Servers wird beim ersten Kontakt gespeichert (StrictHostKeyChecking=accept-new, eigene known_hosts); ändert er sich später, schlägt die Sicherung fehl. Der Zielpfad wird bei Bedarf angelegt.
• rsync-Daemon: rsync://[benutzer@]server:port/modul/pfad. Ein Modul-Passwort wird nur für root lesbar gespeichert und per --password-file übergeben.
• Löschen: Optional löscht rsync auf dem Ziel, was in der Quelle gelöscht wurde (--delete).
• Bandbreite: optionales Limit in KiB/s.

S3-Ziele

Endpunkt (https; http nur für Server im lokalen Netz), Region, Bucket, optionales Präfix, Access Key ID und Secret Access Key. Mit Verschlüsselung legt Bunkerbox einen rclone-crypt-Remote über Bucket/Präfix; Inhalte und optional Datei- und Ordnernamen werden vor dem Hochladen verschlüsselt. Ohne das Verschlüsselungspasswort lassen sich die Daten nicht wiederherstellen – bewahre es zusätzlich außerhalb des NAS auf.

Geheimnisse (Secret Key, Verschlüsselungs- und Modul-Passwort) stehen nur in /appdata/bunkerbox/data/backup/secrets/<auftrag>.json (Verzeichnis 700, Datei 600) und werden nie angezeigt. Beim Bearbeiten bleiben sie erhalten, wenn das Feld leer bleibt. Für jeden Lauf schreibt Bunkerbox eine temporäre rclone-Konfiguration (600) und löscht sie danach.

Aufbewahrung

Die Regeln letzte, tägliche, wöchentliche und monatliche behalten die neuesten Stände bzw. den neuesten Stand pro Tag, Woche (ab Montag) und Monat; alles andere wird gelöscht.

• rsync und S3: Geänderte und gelöschte Dateien wandern pro Lauf in <ziel>/.bunkerbox-versions/<JJJJMMTT-hhmmss>/. Die Regeln bestimmen, welche dieser Versionsordner bleiben. Stehen alle Regeln auf 0, ist das Ziel ein reiner Spiegel ohne Versionen.
• Appdata: Die Regeln gelten für die Snapshots <dataset>@backup-<auftrag>-<JJJJMMTT-hhmmss> dieses Auftrags (mindestens eine Regel muss größer als 0 sein). Andere Snapshots bleiben unberührt.

Appdata-Snapshots

1. Die gewählten Apps, die gerade laufen, werden mit docker compose down angehalten, die gewählten Container und VMs gestoppt. Lässt sich eine Instanz nicht anhalten, wird sie im laufenden Zustand gesichert und der Lauf endet mit einer Warnung.
2. Jedes gewählte Dataset wird rekursiv gesnapshottet (also auch eigene Datasets einzelner Apps unter /appdata/<app>).
3. Alles, was vorher lief, wird wieder gestartet – auch wenn der Snapshot oder das Anhalten einer App mittendrin fehlschlägt. Was sich nicht wieder starten lässt, nennt die Benachrichtigung. Bunkerbox merkt sich vor jedem Anhalten, was der Lauf gestoppt hat; wird Bunkerbox mitten im Lauf neu gestartet, startet es diese Apps und Instanzen beim nächsten Start wieder.
4. Optional wird der Snapshot-Inhalt (<mountpoint>/.zfs/snapshot/<snapshot>/) pro Dataset nach <ziel>/<dataset>/ übertragen. Datasets ohne Einhängepunkt werden dabei übersprungen und als Warnung im Protokoll vermerkt – das betrifft die Volumes von Incus-Instanzen (Container mit mountpoint=legacy, VMs als zvol). Instanzen bleiben daher nur als lokale Snapshots erhalten; für eine Kopie außer Haus eignen sich Exporte (incus export) in eine Freigabe, die ein rsync- oder S3-Auftrag mitnimmt.
5. Alte Snapshots des Auftrags werden nach der Aufbewahrung entfernt.

Die Pause dauert meist nur Sekunden, weil ein ZFS-Snapshot sofort fertig ist; übertragen wird erst danach.

Wiederherstellen

Backup → Wiederherstellen listet die Snapshots aller Appdata-Aufträge.

• Apps wiederherstellen: Die gewählten App-Verzeichnisse /appdata/<app> werden mit rsync --delete aus dem Snapshot zurückkopiert. Laufende Apps werden dafür angehalten und danach gestartet. Das funktioniert immer, auch wenn Bunkerbox selbst im selben Dataset liegt.
• Rollback: Das Dataset und seine Unter-Datasets mit demselben Snapshot werden per zfs rollback vollständig zurückgesetzt. Neuere Snapshots gehen dabei verloren und müssen ausdrücklich freigegeben werden. Liegt Bunkerbox selbst (/appdata/bunkerbox) im Dataset, ist der Rollback gesperrt – sonst würde er die laufende Installation zurücksetzen. Angehalten werden nicht nur die Apps und Instanzen des Auftrags, sondern alle, deren Daten in einem der zurückgesetzten Datasets liegen (/appdata/<app> bzw. das Volume der Instanz im Pool).

Beides wird mit dem Snapshot-Namen bestätigt und erscheint im Verlauf des Auftrags.

Wiederherstellung von externen Zielen (manuell)

• rsync: Daten mit rsync -a <benutzer>@<server>:<pfad>/<ordner>/ /ziel/ zurückholen; ältere Stände einzelner Dateien liegen unter .bunkerbox-versions/.
• S3 ohne Verschlüsselung: rclone copy mit einem S3-Remote auf bucket/präfix/<ordner>.
• S3 mit Verschlüsselung: einen crypt-Remote mit demselben Passwort und derselben Namensverschlüsselung über bucket/präfix anlegen (rclone config), dann rclone copy crypt:<ordner> /ziel/.
• Übertragene Appdata-Snapshots: liegen unter <ziel>/<dataset>/ als normale Ordner. Apps anhalten, Verzeichnis zurückkopieren, Apps starten.