Sicherung und Wiederherstellung

Skrum ist die All-in-one-KI-Projektsteuerung — Team-Chat, Aufgaben und Sprints, native Videomeetings und eingehende Code-Aktivität in einem Arbeitsbereich, wobei jede KI-Aktion auf eine menschliche Freigabe wartet.

Sicherungen liegen in der Verantwortung des Betreibers. Skrum liefert Skripte und den Aufbewahrungs-Durchlauf; ihr stellt Zeitplan, externes Ziel, Überwachung und Wiederherstellungsübungen bereit.

Wiederherstellungsziele und Zeitplan

• Empfohlener Rhythmus: jede Nacht ein vollständiger Satz und vierteljährlich eine Wiederherstellungsübung. Wer keinen Tagesverlust toleriert, sichert mindestens alle sechs Stunden.
• RPO: höchstens der Abstand zwischen erfolgreichen Sätzen zuzüglich der Dauer eines unterbrochenen Laufs. Eine nächtliche Sicherung erreicht 24 Stunden nur bei überwachten, erfolgreichen Läufen.
• RTO: durch eine zeitgemessene Wiederherstellung produktionsnaher Daten bestimmen. Vier Stunden sind ein erster Betriebswert; maßgeblich ist das Messergebnis.
• Aufbewahrung: als Startwert 7 tägliche, 4 wöchentliche und 12 monatliche vollständige Sätze; mindestens eine Kopie außerhalb von Anwendungshost und primärem Objektspeicher.

Warnt bei verpasstem Lauf, Exit-Code ungleich null oder fehlender MANIFEST.txt. Löscht den letzten bekannten guten Satz erst, wenn der neue Satz samt Prüfsummen vollständig vorliegt.

Sicherung erstellen

./scripts/backup/backup-all.sh

Die Skripte lesen ausschließlich sicherungsbezogene Werte aus der .env im Repository-Stamm, wenn sie im Prozess fehlen. Explizite Variablen — auch leere — haben Vorrang; die Datei wird weder mit source noch mit eval ausgeführt und Geheimnisse werden nicht ausgegeben.

Erforderlich sind MONGODB_URI, DATABASE_URL, S3_ENDPOINT, S3_ACCESS_KEY, S3_SECRET_KEY und S3_BUCKET. BACKUP_TARGET=local schreibt nach BACKUP_DIR; BACKUP_TARGET=s3 lädt unter BACKUP_S3_PREFIX hoch. Mongo, Postgres und Objektspeicher werden nacheinander gesichert. Pausiert eingehende Schreibvorgänge und Worker für ein ruhiges, konsistentes Wiederherstellungsfenster.

Aufbewahrungs-Durchlauf

Ein täglicher retention-sweep-BullMQ-Job archiviert löschfähige Nachrichten, Aufgabenkommentare und Arbeitsgraph-Ereignisse verlustfrei in den Kaltspeicher unter archive/{accountId}/{kind}/{sha256}.ndjson.gz, bevor sie gelöscht werden. Die Aufbewahrungstage je Stufe folgen historyDays (30 / 90 / 365 / unbegrenzt). Unbegrenzte Stufen tun nichts.

Erwartungen an die Wiederherstellung

Die Wiederherstellung ist destruktiv: Mongo verwendet --drop, Postgres --clean --if-exists, und die Objektspeicher-Spiegelung entfernt überschüssige Objekte. Plant ein Wartungsfenster, stoppt API-/Worker-Schreibvorgänge und prüft die Zielsysteme.

./scripts/backup/restore-all.sh <BACKUP_SET_DIR_OR_S3_URI>

Der Befehl prüft Manifest und sämtliche Archiv-Prüfsummen vor jeder Änderung und stellt dann Mongo, Postgres und MinIO wieder her. Vor dem Öffnen für Schreibzugriffe:

1. API und Worker starten und alle Healthchecks abwarten.
2. Anmeldung sowie bekannte Workspace-, Projekt-, Aufgaben-, Nachrichten- und Datei-Downloads prüfen.
3. Queue-Tiefe, Migrationsstand und aktuelle Audit-Ereignisse prüfen.
4. Start-/Endzeit, Sicherungssatz und Smoke-Test-Ergebnis im Wiederherstellungsprotokoll festhalten.

FAQ

• Verwaltetes Hosting? Sicherungen liegen bei der verwalteten Stufe in unserer Verantwortung.
• Kann ich das Aufbewahrungsfenster überschreiben? Ja — retention_policies je Konto begrenzt nur nach unten.
• Ersetzt die Anwendungsaufbewahrung Disaster-Recovery-Sätze? Nein, die Lebensdauer vollständiger Sicherungssätze ist eine separate Betriebsrichtlinie.

Siehe auch: Skrum-Dokumentation