Notfallwiederherstellung

Dies ist das Betriebs-Runbook zum Wiederherstellen von Orimora nach einem echten Vorfall. Es ergänzt Backup & Wiederherstellung (was gesichert wird + Zeitplan). Halte eine Kopie dieser Seite — und deinen Recovery-Code — dort bereit, wo du sie erreichst, wenn die Instanz steht.

Ziele

Kennzahl	Ziel	Hinweise
RPO (max. akzeptabler Verlust)	24 h	Tägliches Backup um 03:00 UTC (BACKUP_SCHEDULE).
RTO (max. akzeptable Ausfallzeit)	4 h	Manuelle Wiederherstellung + Boot; mit diesem Runbook machbar.

Was du zum Wiederherstellen brauchst

1. Den aktuellen DB-Dump (orimora-db-<ts>.dump, pg_dump-Custom-Format).
2. Das aktuelle Uploads-Archiv (uploads-<ts>.tar.gz).
3. Den Recovery-Code — den privaten age-Schlüssel (AGE-SECRET-KEY-…), der bei der Einrichtung einmalig unter Einstellungen → Admin → Backups angezeigt wird.

Gefahr

Off-Site-Kopien und der In-App-Download sind mit dem öffentlichen Schlüssel des Recovery-Codes verschlüsselt. Ohne den privaten Schlüssel sind sie nicht zu entschlüsseln, und wir können ihn nicht für dich wiederherstellen. Bewahre ihn in einem Passwortmanager und an einem Offline-Ort auf.

Off-Site-Artefakte heißen *.age (verschlüsselt). Lokale Kopien auf dem Host unter BACKUP_PATH sind Klartext (der Host hält ohnehin die Live-DB) — wenn das Host-Volume noch existiert, überspringe den Entschlüsselungsschritt.

Wiederherstellungsablauf (DB + Uploads)

Der PostgreSQL-Client muss zur Major-Version (16) des Servers passen — das Image bringt postgresql16-client mit. age und rclone sind ebenfalls im Image enthalten.

# 0. App stoppen, damit während der Wiederherstellung nichts schreibt.
docker compose stop app

# 1. Aktuelle Off-Site-Artefakte holen (Beispiel: rclone-Remote namens "offsite").
rclone copy offsite:orimora ./restore --include '*.age'

# 2. Mit dem Recovery-Code entschlüsseln (privater age-Schlüssel).
printf '%s\n' "$AGE_SECRET_KEY" > /tmp/orimora-recovery.key
age -d -i /tmp/orimora-recovery.key -o ./restore/db.dump        ./restore/orimora-db-<ts>.dump.age
age -d -i /tmp/orimora-recovery.key -o ./restore/uploads.tar.gz ./restore/uploads-<ts>.tar.gz.age
shred -u /tmp/orimora-recovery.key   # Schlüssel nicht auf der Platte lassen

# 3. Datenbank wiederherstellen (in eine saubere DB).
#    Entweder bestehende DB löschen+neu anlegen, oder in eine frische restoren und DATABASE_URL umbiegen.
pg_restore --clean --if-exists --no-owner --no-privileges \
  --dbname="$DATABASE_URL" ./restore/db.dump

# 4. Uploads wiederherstellen (entpackt zurück nach ./uploads/...).
tar -xzf ./restore/uploads.tar.gz -C /app          # Ziel an dein Uploads-Elternverzeichnis anpassen

# 5. App starten. Der Entrypoint führt Migrationen fail-closed aus, bevor er ausliefert.
docker compose up -d app

Nach dem Boot prüfen: Login funktioniert, ein Dokument mit Anhang rendert sein Bild (Blob aufgelöst), und Einstellungen → Admin → Backups zeigt grünen Health-Status.

Tipp

Lokale Klartext-Abkürzung: Wenn das Host-Volume überlebt, sind die Artefakte unter BACKUP_PATH bereits Klartext — überspringe Schritt 1–2 und pg_restore / tar -xzf sie direkt.

Fehlerszenarien

Szenario	Was passiert ist	Maßnahme
(a) Volume-/Host-Verlust	Server oder Platte ist weg.	Neuen Host bereitstellen, Image installieren, Off-Site-*.age ziehen, vollständigen Ablauf fahren.
(b) Korrupte DB	DB unlesbar, Host intakt.	Lokalen Klartext-Dump nutzen (Entschlüsselung überspringen); pg_restore --clean in dieselbe DB.
(c) Fehlerhafte Migration	Eine Migration hat Schema/Daten zerlegt.	Letzten Pre-Vorfall-Dump wiederherstellen, dann den korrigierten Build deployen.
(d) Ransomware / Totalverlust	Host kompromittiert, lokale Backups weg.	Nur aus der Off-Site-Kopie wiederherstellen. Genau dafür sind Off-Site + Verschlüsselung Pflicht.

Off-Site-Ziele (S3-frei) — rclone-Rezepte

Off-Site nutzt ein rclone-Remote (BACKUP_RCLONE_REMOTE). rclone liest seine Konfiguration aus rclone.conf oder RCLONE_CONFIG_*-Env. Bevorzuge schlüssel-/passwortbasierte Backends (kein OAuth auf einem Headless-Server). Einmal mit rclone config einrichten, dann den Remote-Pfad setzen.

# SFTP zu einer zweiten Maschine (am universellsten — jeder mit einem zweiten Linux-Rechner)
[offsite]
type = sftp
host = backup.example.com
user = orimora
key_file = /home/orimora/.ssh/id_ed25519
# → BACKUP_RCLONE_REMOTE=offsite:orimora-backups

# Backblaze B2 (günstiger Objektspeicher, S3-frei, schlüsselbasiert)
[offsite]
type = b2
account = <keyId>
key = <applicationKey>
# → BACKUP_RCLONE_REMOTE=offsite:my-orimora-bucket

# WebDAV (Nextcloud / generisch)
[offsite]
type = webdav
url = https://cloud.example.com/remote.php/dav/files/orimora/
vendor = nextcloud
user = orimora
pass = <obscured — via `rclone obscure` setzen>
# → BACKUP_RCLONE_REMOTE=offsite:orimora-backups

Tipp

Sicherstes Muster — vom Backup-Host ziehen. Statt dass die App pusht, lässt du einen separaten, gehärteten Backup-Host das Off-Site-Bucket nach eigenem Zeitplan per rclone/rsync ziehen. Der App-Host hält dann keine Zugangsdaten zum Backup-Speicher — eine Kompromittierung der App kann die Backups weder erreichen noch löschen.

Drill

Führe mindestens monatlich einen vollständigen Restore-Drill durch, sowie nach jeder Änderung an der Backup-Pipeline. CI fährt bei jedem Push den Round-Trip-Restore und den Encrypt→Off-Site-Round-Trip; der monatliche Drill übt den echten, durchgängigen manuellen Ablauf gegen eine Wegwerf-Umgebung.

Checkliste:

1. Off-Site-Artefakte vorhanden und aktuell.
2. Mit dem Recovery-Code entschlüsseln.
3. pg_restore in eine Wegwerf-DB.
4. Tabellenanzahl stimmt mit der Quelle überein.
5. Ein bekanntes Dokument und sein Anhang lösen auf.
6. Die Wall-Clock-Zeit festhalten — sie muss ≤ RTO (4 h) liegen.

Hinweis

Vor dem Go-Live ist ein Drill in Produktionsgröße gegen ein repräsentatives Datenvolumen erforderlich, um die 4-h-RTO zu validieren; der Round-Trip in Dev-Größe läuft in Sekunden, beweist aber nicht die Restore-Zeit bei realem Volumen.

Siehe auch

• Backup & Wiederherstellung — was gesichert wird, Zeitplan, Verschlüsselungs-Setup
• Konfiguration — BACKUP_*- und Off-Site-Variablen