homelab-infra/docs/SERVICES_RECOVERY.md

Services Recovery - KalliLab CORE

Status: Initiale Recovery-Baseline 2026-05-26, aus dem Audit 2026-05-25 abgeleitet. Verwandte Docs: docs/DISASTER_RECOVERY.md, docs/RESTORE_MATRIX.md, docs/STORAGE_LAYOUT.md, docs/SECRETS_MAP.md

Zweck

Der Share /mnt/user/services/ ist recovery-kritisch, weil dort GitOps- und Host-Automation-Pfade liegen. Dieses Dokument beschreibt, welche Services-Pfade gesichert werden muessen und wie ein Kaltstart ohne laufendes Komodo gedacht ist.

Kritische Pfade

Pfad	Zweck	Kritikalitaet	Backup-Anforderung
/mnt/user/services/homelab-infra	Host-Repo-Clone fuer Automation/Posture	hoch	Borg + GitHub/Gitea Mirror
/mnt/user/services/stacks	Komodo Stack Workspaces	hoch	Borg, vor strukturellen Aenderungen extra sichern
/mnt/user/services/gitea/git/repositories	Gitea Repository-Inhalte	kritisch	Borg + separater Mirror <= 6 h
/mnt/user/services/posture-check	Hostseitig ausgefuehrte Checks	hoch	Borg + Repo-Abgleich
/mnt/user/appdata/secrets	Runtime Secrets	kritisch	Borg + ausgewählte analoge/off-system Kopien

Gitea Repository Mirror

Ziel: Verlustfenster fuer /mnt/user/services/gitea/git/repositories/ auf maximal 6 Stunden begrenzen.

Optionen:

Option	Bewertung
git bundle je Repository auf zweites Medium	Sehr gut fuer Git-Recovery, transparent, gut pruefbar
rsync auf externe Platte oder zweiten Host	Einfach, aber Ziel muss regelmaessig erreichbar und geprueft sein
Separates Borg-Repo mit kurzem Schedule	Konsistent zum bestehenden Backup, aber wieder Borg-/Passphrase-abhaengig

Empfohlener Start:

1. ops/borg-ui/scripts/gitea-bundle-mirror.sh auf dem Host ausfuehren.
2. Ziel /mnt/user/backups/git-bundles/gitea in Borg/off-site Scope aufnehmen.
3. Job alle 6 Stunden oder mindestens vor Borg ausfuehren.
4. Stichprobe: ein Bundle in Wegwerfpfad klonen.

Erstlauf 2026-05-26: 4 Gitea-Bundles erzeugt, Checksums OK, homelab-infra.bundle in Restore-Lab geklont und git fsck sauber. Offen bleibt die dauerhafte Host-Zeitplanung.

Erfolgskriterium:

git clone /path/to/repo.bundle /tmp/repo-restore-test
git -C /tmp/repo-restore-test fsck

Komodo Bootstrap

Problem: Komodo verwaltet Stacks, ist aber selbst Teil des Recovery-Pfads. Ein kalter Host darf nicht voraussetzen, dass Komodo schon laeuft.

Komodo ist deshalb bewusst kein normaler Auto-Deploy-Stack: der komodo-Self-Stack hat keinen aktiven Gitea-Webhook. Recovery und Aenderungen laufen ueber den dokumentierten Bootstrap-Pfad und muessen nach dem Start in Komodo validiert werden.

Minimaler Wiederanlauf:

1. Docker und externe Netze herstellen (frontend_net, backend_net, ggf. weitere dokumentierte Netze).
2. Repo aus Gitea/GitHub Mirror klonen.
3. Komodo Compose aus ops/komodo/docker-compose.yml oder einem spaeteren Bootstrap-Pfad starten.
4. Erforderliche .env/Secrets aus Host-Secret-Backup wiederherstellen.
5. Komodo-Core, Periphery und Mongo starten.
6. Web-UI und Periphery-Verbindung pruefen.

Offene Aufgabe:

• Entscheidung 2026-05-26: ops/komodo/docker-compose.yml bleibt die verbindliche Bootstrap-Quelle. Der komodo-Self-Stack hat keinen aktiven Gitea-Webhook und ist nicht der Recovery-Anker.
• Offen bleibt nur ein spaeterer Trockenlauf, bei dem die Komodo-Startkommandos gegen echte Restore-Pfade getestet werden.

Validierung:

docker compose -f ops/komodo/docker-compose.yml config
docker compose -f ops/komodo/docker-compose.yml up -d
docker ps --filter "name=komodo"

Secrets Recovery Reihenfolge

Authoritativ ist docs/SECRETS_MAP.md. Fuer den Kaltstart ist diese Reihenfolge praktisch:

1. Borg-Passphrase analog/off-system beschaffen.
2. Borg-Repo-Zugang/SSH-Key wiederherstellen.
3. /mnt/user/appdata/secrets/ aus Borg wiederherstellen.
4. Komodo Stack ENV / Recovery ENV wiederherstellen.
5. Gitea Secrets und SSH-Material wiederherstellen.
6. Traefik/Cloudflare Secret wiederherstellen.
7. App-spezifische Secrets nach Tier-Reihenfolge wiederherstellen.

Break-glass Regeln

• Keine Secret-Werte in Git oder Tickets kopieren.
• Restore-Tests laufen in Wegwerfpfaden, nie direkt gegen produktive Pfade.
• Wenn Gitea und Komodo beide down sind, gewinnt der externe GitHub-Mirror als Repo-Quelle.
• Wenn Borg ohne Passphrase nicht entschluesselbar ist, ist Recovery blockiert. Die Offline-Sicherung wurde am 2026-05-26 vom Operator bestaetigt; bei Reviews nur pruefen, dass sie weiterhin auffindbar und lesbar ist.

Naechste Aufgaben

Status	Aufgabe
erledigt (Skript + Host-Test)	Gitea-Bundle- oder Mirror-Mechanik final entscheiden
erledigt	Komodo-Bootstrap-Quelle finalisieren
offen	Restore-Kommandos nach erstem Trockenlauf mit echten Pfaden ergaenzen
erledigt	Services-Recovery in docs/DISASTER_RECOVERY.md verlinken