nexo312/trading-system-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trading-system-docs/tolaria/RECOVERY_RUNBOOK.md
Red Queen 819fd8a6ff tolaria: Mission 002 B1 Foundation & Backup docs (10 files) 
- BACKUP_ARCHITECTURE, STORAGE_MAP, RECOVERY_RUNBOOK
- TRANSFORMATION_BASELINE, DUPLICATE_RESOLUTION_PLAN
- CANONICAL_KNOWLEDGE_PRINCIPLE, SEARCH_ARCHITECTURE_PROPOSAL
- KNOWLEDGE_GRAPH_PRINCIPLE, FORGEJO_TOLARIA_SYNC_PRINCIPLE
- HOST_CONTAINER_DISCOVERY

Fresh Checker PASS (deleg_a19028bc). No productive vault mutation.
2026-08-25 05:21:29 +00:00

3.4 KiB
Raw Blame History

DISASTER RECOVERY RUNBOOK — Tolaria (Mission 002)

Datum: 2026-08-25 · Red Queen · Status: GETESTET (isolierter Restore PASS)

Frage: "Wenn Tolaria morgen kaputt ist, wie bekommen wir den letzten sicheren Zustand zurück?" Antwort: Dieses Runbook beschreibt den kontrollierten, getesteten Weg.

⚠️ WICHTIG: Dieser Runbook ist manuell. Es wird kein automatischer, gefährlicher Restore aktiviert. Jeder Restore erfordert ausdrückliche Freigabe.

PRECONDITIONS

  • Backup-Verzeichnis vorhanden: /opt/data/tolaria_backups/TOLARIA-BACKUP-YYYYMMDD-HHMMSS/
  • Manifest manifest.json vorhanden und RESULT=SUCCESS
  • BACKUP_SHA256 im Manifest entspricht dem Neu-Berechnen (Integrity)
  • Backup-Zielpfad (isolierter Restore) existiert bzw. ist erzeugbar

STEPS

1. STOP SERVICES

  • Tolaria-Dienst stoppen, falls er aktiv schreibt (während Restore auf prod)
  • Hinweis: Restore-Test läuft immer isoliert — produktive Services werden für Tests nie gestoppt

2. SELECT BACKUP

  • Neuestes verifiziertes Backup wählen: TOLARIA-BACKUP-YYYYMMDD-HHMMSS
  • Referenz-Baseline: TOLARIA-BACKUP-20260825-051420 (Pre-Transformation-Anker)

3. VERIFY BACKUP

  • manifest.json prüfen: RESULT=SUCCESS, FILE_COUNT, SIZE
  • Unabhängig verifizieren (nicht nur "exit 0"):
    • jede Datei existiert + SHA-256 stimmt mit Manifest überein
    • Manifest-BACKUP_SHA256 neu berechnen und vergleichen
  • Befehl: python3 bin/tolaria_backup.py verify TOLARIA-BACKUP-<ID>

4. PRESERVE BROKEN STATE (wichtig)

  • Vor dem Überschreiben des produktiven Vaults: den defekten Zustand sichern/kopieren (z.B. /app/vault → /app/vault.broken) — nur wenn prod angefasst wird. Für den normalen Restore-Test ist dies nicht nötig.

5. RESTORE DATA

  • Isolierte Zielumgebung für Tests: /opt/data/tolaria_restore_test/<BACKUP_ID>/
  • Produktiven Vault niemals für Tests überschreiben.
  • Restore: alle manifest["FILES"]-Dateien aus Backup in Zielverzeichnis kopieren.

6. RESTORE CONFIG

  • Falls App-Config (~/.config/com.laputa.app/, ~/.laputa/) gesichert wurde: wiederherstellen. Aktuell UNKNOWN (kein Host-Zugang) → als Annahme behandeln.

7. PERMISSIONS

  • Sicherstellen, dass wiederhergestellte Dateien lesbar/schreibbar sind (Owner/Berechtigungen des Tolaria-Benutzers).

8. START

  • Tolaria-Dienst starten (falls gestoppt).

9. HEALTH CHECK

  • Port 5173 erreichbar.
  • Vault-API POST /api/vault/list {"path":"/app/vault"} liefert 84 .md.

10. DATA CHECK

  • Anzahl Dateien == Manifest FILE_COUNT.
  • Stichproben-Hashes stimmen.

11. SEARCH CHECK

  • Suche funktioniert (keyword-Substring; semantic identisch — kein Vector-Store).

12. GRAPH CHECK

  • Kein implementierter Graph vorhanden (nur ADR-Doku). Kein Check nötig.

13. ROLLBACK OF RESTORE

  • Falls Restore fehlschlägt: Zielverzeichnis verwerfen (isoliert), produktiven Vault NICHT anfassen, Runbook-Status an Christian melden.

Annahmen & UNKNOWN

  • Host-Restore-Prozedur (Container-Neubau): UNKNOWN ohne Docker/Host-Zugang. Ports 5173 (Tolaria) / 3000 (Forgejo) sind erreichbar; Container-Provisionsmethode ist nicht verifiziert.
  • App-Config-Lage: UNKNOWN (nur mit Container-Shell verifizierbar).

Verifikation (Test am 2026-08-25)

  • Restore-Test: PASS — 454/454 Dateien, Hash-Match, isoliert, produktiver Vault unangetastet (HEAD 69aecf2 unverändert).