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

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

Vault-Dateien (84 .md) + Hashes
Vault-Git-Metadaten
App-Source (optional, rebuildbar)

4. Restore-Reihenfolge

Vault-Dateien zuerst (kritisch)
Git-Metadaten wiederherstellen (falls HEAD-Marker gewünscht)
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).

3.4 KiB Raw Blame History