Backup & Wiederherstellung

Orimora enthält ein automatisches Backup-System, das tägliche Datenbank-Dumps und wöchentliche Markdown-Exporte erstellt.

Konfiguration

Füge die folgenden Umgebungsvariablen zu deiner .env-Datei hinzu:

BACKUP_ENABLED=true
BACKUP_PATH=/backups/orimora
BACKUP_RETENTION_DAILY=7
BACKUP_RETENTION_WEEKLY=4
BACKUP_SCHEDULE=0 3 * * *

Variable	Beschreibung	Standard
BACKUP_ENABLED	Automatische Backups aktivieren	true in Prod
BACKUP_PATH	Verzeichnis für Backup-Dateien	/backups/orimora
BACKUP_RETENTION_DAILY	Anzahl täglicher DB-Dumps	7
BACKUP_RETENTION_WEEKLY	Anzahl wöchentlicher Markdown-Exporte	4
BACKUP_SCHEDULE	Cron-Ausdruck (UTC)	0 3 * * *
BACKUP_S3_BUCKET	Geparst, aber nicht verdrahtet — für S3-kompatibles Off-Site BACKUP_RCLONE_REMOTE nutzen (rclone erreicht S3-Ziele)	nicht gesetzt
BACKUP_RCLONE_REMOTE	rclone-Remote für verschlüsselte Off-Site-Kopien (S3-frei)	nicht gesetzt
BACKUP_POST_HOOK	Befehl mit jedem Egress-Artefaktpfad (Ziele, die rclone nicht erreicht)	nicht gesetzt
BACKUP_PG_DUMP_TIMEOUT_MS	Timeout für pg_dump (ms)	300000 (5 Min.)

Achtung

BACKUP_ENABLED ist in docker-compose.yaml (Produktion) standardmäßig true. Explizit mit BACKUP_ENABLED=false deaktivieren, falls Backups extern übernommen werden (z. B. Coolify-DB-Backup oder verwalteter Datenbankdienst).

Backup-Ebenen

Datenbank (täglich)

Ein vollständiger PostgreSQL-Dump mit pg_dump --format=custom. Dies ist die primäre Backup-Methode und erfasst alle Daten einschließlich Dokumente, Benutzer, Einstellungen und Metadaten.

Markdown-Export (wöchentlich)

Jeden Sonntag exportiert Orimora alle Sammlungen als ZIP-Dateien mit Markdown-Dateien und YAML-Frontmatter. Diese sind menschenlesbar und können in andere Systeme (einschließlich Obsidian) importiert werden.

Uploads (mit jedem DB-Backup)

Anhänge werden neben dem Datenbank-Dump als uploads-<ts>.tar.gz archiviert, sodass eine einzige Wiederherstellung Dokumente und ihre Bilder zurückbringt.

Bei STORAGE_DRIVER=s3 liegen Uploads im Bucket, nicht auf der lokalen Platte — deshalb zeigt Einstellungen → Admin → Backups eine Uploads-Sicherungs-Wahl:

• Provider-verwaltet (Default) — den Bucket über seine eigene Versionierung / Replikation sichern. Orimora überspringt das Uploads-Archiv (und vermerkt das im Log), statt ein leeres zu schreiben.
• In Backups replizieren — Orimora lädt bei jedem Lauf den ganzen Bucket ins Uploads-Archiv, sodass dieselbe Verschlüsselungs- + Off-Site-Pipeline greift. Schwerer (Egress pro Lauf); am besten für kleine Buckets oder eine Kopie außerhalb deines S3-Providers.

Redis

Sessions und Queues sind flüchtig — nicht Teil des Backup-Sets. Nutzer melden sich nach einer Wiederherstellung einfach neu an, und der BullMQ-Backup-Scheduler registriert sich beim Boot selbst neu. Keine Redis-Wiederherstellung nötig.

Verschlüsselung & Off-Site-Replikation

Das ist der Teil, der aus „ich habe einen Dump auf derselben Maschine” echte Notfallwiederherstellung macht. Ohne eine Off-Site-, verschlüsselte Kopie verliert ein Host-Verlust oder Ransomware-Vorfall alles.

Recovery-Code (age-Verschlüsselung)

Off-Site-Kopien und der In-App-Download-Button sind mit age verschlüsselt. Bei der Einrichtung zeigt Einstellungen → Admin → Backups den Recovery-Code (einen privaten AGE-SECRET-KEY-…-Schlüssel) einmalig an.

Gefahr

Bewahre den Recovery-Code in einem Passwortmanager und an einem Offline-Ort auf. Off-Site-Artefakte (*.age) sind ohne ihn nicht zu entschlüsseln, und wir können ihn nicht für dich wiederherstellen. Lokale Kopien unter BACKUP_PATH bleiben Klartext (der Host hält ohnehin die Live-DB).

Off-Site-Ziel (rclone, S3-frei)

Setze BACKUP_RCLONE_REMOTE auf ein rclone-Remote, dann repliziert Orimora jedes verschlüsselte Artefakt off-host. rclone unterstützt SFTP, Backblaze B2, WebDAV/Nextcloud und Dutzende S3-freie Backends — konfigurierbar in der App unter Einstellungen → Admin → Backups oder per rclone config. Rezepte und das sicherste „vom gehärteten Backup-Host ziehen”-Muster stehen im Notfallwiederherstellungs-Runbook.

Admin-Oberfläche

Navigiere zu Einstellungen → Admin → Backups, um:

• Aktuellen Backup-Status und Gesundheit einzusehen
• Backup-Verlauf durchzusehen
• Manuell ein Backup auszulösen
• Den Recovery-Code anzuzeigen und zu kopieren (einmalig bei der Einrichtung)
• Das Off-Site-Ziel (rclone-Remote) zu konfigurieren und einen Verbindungstest zu fahren
• Das letzte Backup zu verifizieren (zerstörungsfreier Integritätscheck) und der geführten Wiederherstellung zu folgen

Achtung

Die In-App-Wiederherstellung ist bewusst geführt, nicht ein Klick — über eine laufende Instanz zu restoren ist destruktiv. Die UI führt dich durch die sicheren Schritte; der vollständige Kommandozeilen-Ablauf steht im Notfallwiederherstellungs-Runbook.

Wiederherstellung

Vollständige Wiederherstellung

# Anwendung stoppen
docker compose stop app

# Datenbank wiederherstellen
pg_restore --clean --if-exists --dbname=knowledgebase /backups/orimora/orimora-db-ZEITSTEMPEL.dump

# Uploads wiederherstellen
rsync -av /backup-quelle/uploads/ /app/uploads/

# Neu starten
docker compose up -d app

Einzelne Sammlung

Importiere eine Markdown-ZIP-Datei über Einstellungen → Sammlung → Import.

Einzelnes Dokument

Nutze die integrierte Revisionsverlauf-Funktion, um eine frühere Version eines Dokuments wiederherzustellen.

Gesundheitsüberwachung

Das System warnt, wenn das letzte erfolgreiche Backup älter als 48 Stunden ist. Nutze die Status-API für externes Monitoring:

GET /api/admin/backup.status

Gibt healthOk: true/false und Details zum letzten Backup zurück.

Wiederherstellungsziele & Runbook

Kennzahl	Ziel	Getrieben von
RPO (max. Datenverlust)	24 h	Tägliches Backup um 03:00 UTC (BACKUP_SCHEDULE)
RTO (max. Ausfallzeit)	4 h	Manuelle Wiederherstellung + Boot, mit dem Runbook zur Hand

Den vollständigen Schritt-für-Schritt-Ablauf (entschlüsseln → pg_restore → Uploads → Boot), Fehlerszenarien, Off-Site-rclone-Rezepte und die monatliche Drill-Checkliste findest du im Notfallwiederherstellungs-Runbook.