Osiris selbst sichern

Osiris schützt die Daten seiner Kunden; die Osiris-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.

2. `.env` und `OSIRIS_MASTER_KEY`

.env enthält jedes Secret, mit dem Osiris läuft — Datenbankpasswörter, BETTER_AUTH_SECRET, das Entra-Client-Secret und OSIRIS_MASTER_KEY. Speziell der Verlust von OSIRIS_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 OSIRIS_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 osiris-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; Osiris unterstützt zusätzlich eines oder mehrere Kopie-Ziele je Mandant, damit ein einzelner Speicherausfall nicht jede Kopie trifft (siehe Backups und Zeitpläne).

4. Caddys Zertifikatsdaten

Die Volumes caddy-data/caddy-config enthalten das automatisch bezogene TLS-Zertifikat für OSIRIS_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 Osiris-Server

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

osiris-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

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

osiris-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 OSIRIS_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 OSIRIS_MASTER_KEY die eigenständige Wiederherstellung ohne laufenden Server möglich.