Backup und Disaster Recovery

ObjectOS selbst ist zustandslos — die Laufzeitumgebung kann aus dem Container-Image neu aufgebaut werden. Bei Backups geht es um die Daten, von denen ObjectOS abhängt, nicht um ObjectOS selbst. Planen Sie die Wiederherstellung rund um diese Datensätze.

Was gesichert werden muss

ObjectOS benötigt kein separates Backup seines Container-Dateisystems. Cache-Verzeichnisse (OS_CACHE_DIR) sind neu aufbaubar.

Datenbank-Backups

Passen Sie die Strategie an den Treiber an:

Validieren Sie unabhängig vom Treiber, dass:

• Backups innerhalb des RPO des Kunden abgeschlossen werden;
• eine frische Datenbank ObjectOS aus demselben Artefakt starten und Traffic bedienen kann;
• Wiederherstellungstests mindestens einmal pro Quartal durchgängig durchgeführt werden.

SQLite-Deployments

SQLite ist der Standardtreiber und eine legitime Produktionswahl für Single-Node-ObjectOS — Desktop-Apps, interne Tools für ein kleines Team, Edge-/On-Prem-Appliances, Evaluierungsumgebungen. Der Kompromiss ist struktureller Natur: SQLite ist ein Single-Writer und eignet sich daher nicht für Multi-Node-ObjectOS, hohen gleichzeitigen Schreibdurchsatz oder Deployments mit gemeinsam genutzter Datenbank. Verwenden Sie dafür PostgreSQL.

Wenn Sie SQLite in der Produktion betreiben, gehören die Konfiguration, die es sicher macht, und das Backup-Rezept zusammen:

Laufzeitkonfiguration

• WAL aktivieren: PRAGMA journal_mode=WAL (Leser blockieren den Schreiber nicht; absturzsicher).
• PRAGMA synchronous=NORMAL ist der übliche Desktop-/Single-Node-Standard — sicher mit WAL, deutlich schneller als FULL.
• Halten Sie die Datenbankdatei auf lokalem Datenträger. Legen Sie sie nicht auf NFS, SMB oder in einen von Dropbox / OneDrive / iCloud synchronisierten Ordner, während die Laufzeitumgebung läuft — die Sperrmechanismen von SQLite sind dort unzuverlässig, und dies ist die häufigste Ursache für die Beschädigung von SQLite-Deployments.

Hot-Snapshot (ohne Ausfallzeit)

Die Laufzeitumgebung bedient weiterhin Traffic, während Sie mit der Online Backup API von SQLite oder VACUUM INTO einen Snapshot erstellen:

VACUUM INTO '/var/backups/objectos/db-2026-05-27T13-00Z.sqlite';

Planen Sie ihn (cron, systemd-Timer oder der In-Process-Scheduler) in einem Intervall, das Ihrem RPO entspricht. Versehen Sie jeden Snapshot mit der Artefaktversion, die ihn erzeugt hat, damit Sie Datenbank + Artefakt gemeinsam zurückrollen können (siehe Artefakt-Versionierung unten).

Externe Kopie

Ein lokaler Snapshot übersteht keinen Datenträgerverlust. Übertragen Sie jeden Snapshot in dauerhaften Speicher:

• Server / VM: in S3 oder einen beliebigen S3-kompatiblen Bucket übertragen (Sie haben wahrscheinlich bereits einen für die storage-Capability konfiguriert).
• Desktop-App: den Snapshot in einen vom Benutzer kontrollierten Sync-Ordner schreiben (OneDrive / iCloud / Google Drive) — hier akzeptabel, weil die Snapshot-Datei geschlossen und unveränderlich ist, anders als die Live-Datenbank.

Kontinuierliche Replikation (niedrigeres RPO)

Für ein RPO im Sekundenbereich, ohne SQLite aufzugeben, betreiben Sie Litestream neben dem ObjectOS-Prozess. Es streamt das WAL in S3-kompatiblen Speicher und unterstützt Point-in-Time-Wiederherstellung. Dies ist der empfohlene Weg, wenn ein Single-Node-SQLite-Deployment einen nahezu verlustfreien Betrieb benötigt.

Wiederherstellung

Stoppen Sie die Laufzeitumgebung, ersetzen Sie die Datenbankdatei durch den gewählten Snapshot (oder führen Sie litestream restore aus) und starten Sie die Laufzeitumgebung gegen dieselbe Artefaktversion, die den Snapshot erzeugt hat.

Artefakt-Versionierung

Behandeln Sie veröffentlichte Artefakte als unveränderlich. Versehen Sie jedes Artefakt mit der Release-ID, die zum Kompilieren verwendet wurde (z. B. objectstack-2026-05-24.json). Eine Wiederherstellung in einen bekannten guten Geschäftszustand bedeutet in der Regel:

1. Stellen Sie die Datenbank auf den gewählten Zeitpunkt wieder her.
2. Verweisen Sie ObjectOS erneut auf die Artefaktversion, die zu diesem Zeitpunkt aktiv war.
3. Starten Sie die Laufzeitumgebung neu.

Wenn Sie Artefakte direkt überschreiben, verlieren Sie die Möglichkeit, sauber zurückzurollen — selbst wenn das Datenbank-Backup einwandfrei ist.

RPO-/RTO-Planung

Ein praktikables Ausgangsziel für Kunden-Deployments:

Engere Ziele erfordern Plattformänderungen außerhalb des ObjectOS-Containers selbst (HA-Datenbank, Multi-AZ-Ingress, Warm-Replicas).

Ausfallszenarien, die das Üben wert sind

• Datenbank über einen langen Zeitraum nicht verfügbar. Stellen Sie sicher, dass die Laufzeitumgebung einen klaren 503 ausgibt und dass Probes Pods korrekt als ungesund markieren.
• Artefakt-Regression. Rollen Sie den Artefakt-Zeiger zurück; die Daten sind nicht betroffen.
• Secret-Rotation. Die Rotation von AUTH_SECRET macht jede Session ungültig. Führen Sie sie während eines Wartungsfensters durch oder staffeln Sie sie über die Replicas.
• Regionsausfall. Wenn der Kunde ein regionsübergreifendes Failover benötigt, müssen die Geschäftsdatenbank, der Secret-Manager und der Ingress alle regionsübergreifend ausgelegt sein. ObjectOS selbst kann überall dort laufen, wo das Image verfügbar ist.

Was im Runbook festgehalten werden sollte

• Backup-Zeitplan, Aufbewahrung und On-Call-Kontakt für jeden Datensatz.
• Schritt-für-Schritt-Wiederherstellungsprozedur (zuerst Datenbank, dann Artefakt, dann ObjectOS starten).
• Verifizierungsabfragen, um zu bestätigen, dass die wiederhergestellte Datenbank konsistent ist.
• Rollback-Plan für ObjectOS-Image und Artefaktversion (siehe Upgrade und Rollback).
• Kommunikationsvorlage für kundensichtbare Vorfälle.