# 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).