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 (haben Sie die Datenbank seit 0.4.0 auf einen anderen Datenträger verschoben, liegen die Daten stattdessen im Host-Verzeichnis, das RESTOW_POSTGRES_DATA in der .env nennt, und davon machen Sie den Snapshot), 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. Seit 0.4.0 listet der Reiter Updates diese Dumps unter Datenbanksicherungen, und die Inhaberin oder der Inhaber der Installation kann einen herunterladen (nach einer aktuellen Anmeldung, im Audit-Log festgehalten). Ein Dump enthält die gesamte Datenbank, auch die verschlüsselten Geheimnisse: Bewahren Sie einen heruntergeladenen so sorgfältig auf wie den Master-Key. Siehe Datenbank.

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-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. Der Server lehnt einen Wechsel des Primärziels ab, solange Endpoints aktiv sind (HTTP 409, storage-active-endpoints), weil ein aktiver Agent weiter auf das alte Primärziel schreibt, während es kopiert wird. Um es zu wechseln, widerrufen oder deinstallieren Sie die Rechner, wechseln das Primärziel mit einem Verschieben und melden die Rechner danach neu an: Sie werden zu neuen Endpoints mit neuen Repositories im neuen Primärziel. Seit 0.4.2 kopiert ein Verschieben die endpoints/-Repositories der widerrufenen Rechner mit, geprüft nach Größe und SHA-256 (vor 0.4.2 kopierte es nur tenants/<Mandanten-ID>/), und ihre Backups lassen sich vom neuen Primärziel durchsuchen und herunterladen. Mit „Vorhandene Backups dort belassen, wo sie sind“ bleiben sie auf dem alten Ziel (es wird zum vorherigen Ziel oder zur Kopie), das sich nicht entfernen lässt, solange es sie allein hält. Jedes Repository hat ein eigenes Passwort. Der Server bewahrt es in seiner Datenbank auf und zusätzlich neben dem Repository, versiegelt mit dem Mandantenschlüssel (endpoints/<Endpoint-ID>/restow-repository-password.json). RESTOW_MASTER_KEY und eine Kopie des Speichers genügen also, um es ohne diese Installation zurückzuholen: restow-restore endpoint-password --storage <dir> --key <file|env> --endpoint <id>, danach reines restic (siehe Restore für Server und Clients).

Proxmox-VE-Container und Freigaben legen ihre restic-Repositories ebenso ab, unter pve-guests/<Gast-ID>/ und file-shares/<Freigaben-ID>/ im Primärziel des Mandanten (Freigaben seit 0.4.0), eine Sicherung des Ziels deckt sie also ebenfalls ab. Seit 0.4.2 kopiert ein Speicher-Verschieben diese Repositories mit dem Rest, geprüft nach Größe und SHA-256, und „Vorhandene Backups dort belassen, wo sie sind“ wird abgelehnt, solange Container oder Freigaben Repositories haben (Das primäre Repository ersetzen); vor 0.4.2 kopierte eine Migration nur tenants/<Mandanten-ID>/. Jedes dieser Repositories hat ein eigenes Passwort, das der Server in seiner Datenbank und zusätzlich neben dem Repository aufbewahrt, versiegelt mit dem Mandantenschlüssel.

Mit unveränderbaren Backups (seit 0.4.0) sind die Objekte eines Repositorys auf S3 mit Object Lock für die gewählte Dauer gesperrt, und ein Kopierziel erbt das nicht: siehe Unveränderbare Backups.

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. restow-restore endpoint-password öffnet das Repository-Passwort eines Servers oder Clients (unter endpoints/) und sucht, wie in 0.4.7 gebaut, nicht unter pve-guests/ oder file-shares/: Ein Container- oder Freigaben-Repository ist ein gewöhnliches restic-Repository, und seine versiegelte Passwortdatei (restow-repository-password.json, neben dem Repository) ist vorhanden, aber kein Befehl von restow-restore entsiegelt sie in 0.4.7. Halten Sie das Repository-Passwort dieser Repositories in Ihren eigenen Unterlagen vor, wenn Sie sie ohne diese Installation öffnen müssen.