Restow selbst sichern

Restow schützt die Daten seiner Kunden; die Restow-Installation selbst zu schützen ist eine eigene, manuelle Verantwortung. Vier Dinge zählen.

1. Die PostgreSQL-Datenbank

Enthält die Metadaten jedes Mandanten, die Job-Warteschlange, Einstellungen, den Lizenzstatus und das Audit-Log. Sichern Sie sie mit einem gewöhnlichen pg_dump/pg_dumpall gegen den postgres-Dienst, per Snapshot des pgdata-Docker-Volumes bei gestoppter Datenbank, oder mit dem eigenen konsistenten Snapshot-Mechanismus Ihrer Speicherschicht. Das ist nicht der Chunk-Store: Nur die Datenbank ohne den Chunk-Store wiederherzustellen, hinterlässt Metadaten, die auf nicht vorhandene Daten zeigen. Der optionale Updater sichert die Datenbank vor jedem Update mit pg_dump in sein eigenes Volume und behält die letzten drei Dumps; das ist ein Sicherheitsnetz für das Update, kein Ersatz für Ihre eigene Datenbanksicherung.

2. `.env` und `RESTOW_MASTER_KEY`

.env enthält jedes Secret, mit dem Restow läuft: Datenbankpasswörter, BETTER_AUTH_SECRET, das Entra-Client-Secret und RESTOW_MASTER_KEY. Speziell der Verlust von RESTOW_MASTER_KEY macht jeden verschlüsselten Mandantenschlüssel und damit jede Sicherung und jedes Archivobjekt dauerhaft unlesbar (siehe die Warnung unter Erste Schritte → Installation). Bewahren Sie eine Offline-Kopie von .env (oder zumindest von RESTOW_MASTER_KEY) getrennt vom Server auf, so wie Sie jeden anderen Root-of-Trust-Schlüssel aufbewahren würden.

3. Der Chunk-Store

Wo die verschlüsselten, deduplizierten Sicherungs- und Archivdaten tatsächlich liegen. Nutzen Sie das lokale Standard-Speicherziel, ist das das restow-data-Docker-Volume (STORAGE_LOCAL_PATH=/data/chunks im Container). Sichern Sie es wie jedes andere Datenvolumen. Ist Ihr Primärziel S3-kompatibler Speicher oder eine eingebundene NFS-/SMB-Freigabe, hat dieser Speicher bereits eine eigene Haltbarkeit; Restow unterstützt zusätzlich eines oder mehrere Kopie-Ziele je Mandant, damit ein einzelner Speicherausfall nicht jede Kopie trifft (siehe Backups und Zeitpläne).

Server und Clients, die mit dem Restow-Agent gesichert werden, legen ihre restic-Repositories im selben Speicherziel ab, unter endpoints/<Endpoint-ID>/ im Primärziel des Mandanten; eine Sicherung des Ziels deckt sie also mit ab. Eine Migration des Speicherziels kopiert derzeit nur tenants/<Mandanten-ID>/, nicht endpoints/. Kopieren Sie den Ordner endpoints/ von Hand, bevor Sie das Primärziel wechseln. Bis dahin finden Agents und Aufbewahrung auf dem neuen Ziel ein leeres Repository vor. Jedes Repository hat ein eigenes Passwort, das auf dem Server mit dem Mandantenschlüssel verschlüsselt liegt; bewahren Sie eine Kopie in einem Passwortmanager auf, wenn Sie auch ohne diese Installation wiederherstellen wollen (siehe Restore für Server und Clients).

4. Caddys Zertifikatsdaten

Die Volumes caddy-data/caddy-config enthalten das automatisch bezogene TLS-Zertifikat für RESTOW_APP_DOMAIN. Ihr Verlust ist unbequem (Caddy fordert beim nächsten Start ein neues Zertifikat an), aber nicht gefährlich, daher ist ihre Sicherung optional.

Eigenständige Wiederherstellung, ohne laufenden Restow-Server

Das Speicherformat ist offen und dokumentiert, gerade damit ein Restore auch möglich ist, wenn der Restow-Server selbst nicht mehr existiert: restow-restore, ein kleines eigenständiges CLI-Tool aus dem Workspace packages/cli des Produkt-Repositorys, liest den Chunk-Store direkt.

restow-restore restore \
  --manifest <pfad-oder-key> \  # ein Sicherungs-Manifest: eine lokale Datei, oder ein Key im Speicher
  --storage <verzeichnis>    \  # Pfad zur Wurzel des lokalen Speicher-Backends
  --key <datei|env>          \  # der exportierte Schlüsselbund oder KEK des Mandanten: ein Dateipfad oder ein Umgebungsvariablenname
  --out <verzeichnis>           # Verzeichnis, in das die rekonstruierten Dateien geschrieben werden

restow-restore verify führt dieselben Hash-Prüfungen end-to-end aus, ohne Dateien zu schreiben. Das ist nützlich, um zu bestätigen, dass eine Sicherung oder eine Offline-Kopie davon intakt ist:

restow-restore verify --manifest <pfad-oder-key> --storage <verzeichnis> --key <datei|env>

Beide Befehle melden für jedes Objekt das Ergebnis (ok / skip / FAIL), während sie laufen, und enden mit einem Exit-Code ungleich null, falls etwas fehlschlug, sodass sie sich sauber in eine periodische Prüfung skripten lassen. --key nimmt eines von zwei Dingen entgegen: im Normalfall den RESTOW_MASTER_KEY der Installation (den Schlüsselverschlüsselungsschlüssel). Dieselbe Offline-Kopie aus Abschnitt 2 oben entschlüsselt damit direkt jeden Datenverschlüsselungsschlüssel jedes Mandanten aus dem Speicher; oder, falls Sie den Schlüsselbund eines einzelnen Mandanten separat exportiert haben, diese Export-Datei. Eine eigene Aktion „Schlüsselbund eines Mandanten exportieren“ im Produkt selbst ist geplant, aber noch nicht gebaut. Heute macht das Offline-Halten von RESTOW_MASTER_KEY die eigenständige Wiederherstellung ohne laufenden Server möglich.