# BACKUP ARCHITECTURE — Tolaria Second Brain (Mission 002)

Datum: 2026-08-25 · Red Queen · Status: **UMGESETZT (B1 Foundation)**

> Backup-Strategie für Tolaria. **Git allein ist kein vollständiges Backup** —
> diese Architektur sichert den konsistenten, versionierten und verifizierbaren
> Zustand der kritischen Persistenz.

---

## 1. Was muss gesichert werden (und was nicht)

### SICHERN (kritisch, P1)
- **Vault-Inhalt**: `/app/vault/**` (84 `.md` Dateien) — der kanonische Wissensstand
- **Vault-Git-Metadaten**: `.git/HEAD`, `.git/refs/heads/main`, `.git/logs/HEAD`, `.git/config` — Revisions-Identität (HEAD `69aecf2`)

### OPTIONAL / INFERENCE (P2, bei Host-Zugang)
- Tauri-App-Config `~/.config/com.laputa.app/`, `~/.laputa/` — **UNKNOWN**, ohne Container-Shell nicht verifizierbar

### NICHT gesichert werden (rebuildbar, P3)
- App-Source `/app/tolaria` — rebuildbar aus Forgejo (Source of Truth)
- node_modules, Build-Artefakte, Vite-Cache, Temp — aus Source regenerierbar

> **Entscheidung (EVIDENCE):** Die einzigartige, nicht-rebuildbare Persistenz ist der
> **Vault**. App-Source ist im Forgejo-Repo (master) versioniert. App-Config ist
> UNKNOWN und wird als offener Punkt geführt.

## 2. Konsistenzanforderungen
- Backup wird **read-only** aus der Vault-API gezogen → **keine produktive Mutation**
- Während des Snapshots ändert sich der Vault nicht (read-only; kein Schreibkonflikt)
- Manifest erfasst **eine Momentaufnahme** (alle Dateien + Hashes) → konsistenter Zustand

## 3. Backup-Reihenfolge
1. Vault-Dateien (84 .md) + Hashes
2. Vault-Git-Metadaten
3. App-Source (optional, rebuildbar)

## 4. Restore-Reihenfolge
1. **Vault-Dateien** zuerst (kritisch)
2. Git-Metadaten wiederherstellen (falls HEAD-Marker gewünscht)
3. App-Source nur bei vollständigem Neuaufbau (aus Forgejo, nicht aus Backup)

## 5. Integrity Checks
- Jede Datei: **SHA-256** im Manifest
- **Manifest-BACKUP_SHA256**: kryptografischer Hash über alle (Pfad, Hash)-Paare
- **Restore-Verifikation**: alle Dateien neu einlesen + Hash vergleichen (nicht nur "exit 0")

## 6. Backup-Versionierung & Retention
- **Identifier**: `TOLARIA-BACKUP-YYYYMMDD-HHMMSS` (eindeutig, zeitgestempelt)
- **Manifest** enthält: `BACKUP_ID`, `TIMESTAMP`, `SOURCE`, `COMPONENTS`, `FILE_COUNT`, `SIZE`, `HASH_ALGO`, `BACKUP_SHA256`, `RESULT`
- **Retention**: Baseline-Backup wird **dauerhaft** vorgehalten (Pre-Transformation-Anker). Weitere Backups nach Bedarf.

## 7. Speicherbedarf
- Aktuelles Baseline-Backup: **1.7 MB** (454 Dateien inkl. Git-Metadaten)
- Skaliert mit Vault-Wachstum; unkritisch (<10 MB erwartet)

## 8. Failure Modes
| Risiko | Mitigation |
|---|---|
| API nicht erreichbar (Port 5173 down) | Backup fehlschlägt → kein partielles Ergebnis; Manifest `RESULT=FAIL` |
| Datei beim Lesen fehlerhaft | Einzeln protokolliert; Hash mismatch → `RESULT=FAIL` |
| Manifest-Hash inkonsistent | Independent Verify → detects mismatch |
| Secret-Leak | **Keine Secrets im Manifest/Log**; nur Pfade/Hashes/Größen |

## 9. Secrets
- **Keine Secret-Werte** im Manifest, in Logs oder im Backup.
- Env-Variablen des Tolaria-Containers wurden **nicht** ausgelesen (nur lesend, nicht exportiert).
- Backup-Manifest enthält ausschließlich Metadaten (Pfade, Hashes, Größen, Zeitstempel).

---

**Implementiert:** `bin/tolaria_backup.py` (reproduzierbar) + Baseline `TOLARIA-BACKUP-20260825-051420` (454 Dateien, Integrity PASS, Restore PASS).