📚 HF Wiki

aktualisiert 18:52:56
Wiki / system / disaster_recovery.md

--- type: runbook subject: disaster_recovery version: 1.0 last_reviewed: 2026-04-24 ---

Disaster Recovery Runbook — Viaviva Agent OS

Quelle: v1.6 Teil 10.5 — fünf Szenarien mit konkreten Commands.

Vorab: Wo finde ich welches Backup?

OrtInhaltAufbewahrung
/backup/hourly/hourly-{YYYYMMDD-HHMM}.tar.gzPerfex-DB + Wiki-Bundle24h rollend
/backup/daily/daily-{YYYYMMDD}.tar.gz(.gpg)Komplettes System-Bundle (12 Punkte)7d lokal
Hostinger Snapshot (Panel)wöchentlich via Panel, manuell oder via Hostinger-API falls verfügbarTODO — Chapaty konfiguriert im Hostinger-Control-Panel
GPG Key 1 (Backup)private key bei Chapaty (Vaultwarden + Safe)—
GPG Key 2 (Secrets)private key bei Chapaty—

---

Szenario A: Einzelner Container gestört

Symptom: ein Docker-Service (z.B. n8n, perfex-web) antwortet nicht mehr.

Recovery (5 Min):

  1. docker ps -a → Status prüfen
  2. cd /docker/<service>/ && docker compose restart
  3. Falls persistent kaputt: docker compose down && docker compose up -d
  4. Raj macht das in vielen Fällen automatisch (corrections.md known-fix → compose down+up)

---

Szenario B: Perfex-DB korrumpiert

Symptom: Perfex-Web zeigt Fehler, Queries schlagen fehl, Daten-Inkonsistenzen.

Recovery (max 1h Datenverlust):


# 1. Stop Perfex-Web
cd /docker/perfex && docker compose stop perfex-web-1

# 2. Finde letztes sauberes Hourly-Backup
ls -lt /backup/hourly/ | head -5

# 3. Extract
TMP=$(mktemp -d)
cd $TMP && tar -xzf /backup/hourly/hourly-LATEST.tar.gz

# 4. Import
cat $TMP/perfex_db.sql | docker exec -i perfex-db-1 mysql -uroot -p'47b7eba982b76bb1b2ca2fd3a205f98a' perfex

# 5. Verify
docker exec perfex-db-1 mysql -uroot -p'...' perfex -e "SELECT COUNT(*) FROM tblprojects;"

# 6. Restart Web
cd /docker/perfex && docker compose start perfex-web-1

Datenverlust: max 1 Stunde (zwischen Hourly-Läufen). Bei tiefer Korruption: letztes daily-Backup (max 24h Verlust).

---

Szenario C: N8N-Workflows zerstört

Symptom: Workflows fehlen in der UI, Cron feuert nicht, Webhooks 404.

Recovery (~30 Min):


# 1. Stop N8N
cd /docker/n8n && docker compose stop n8n

# 2. Backup der kaputten SQLite (falls Analyse nötig)
docker cp n8n-n8n-1:/home/node/.n8n/database.sqlite /tmp/broken_n8n.db

# 3. Extract Backup
TMP=$(mktemp -d)
tar -xzf /backup/daily/daily-LATEST.tar.gz -C $TMP
cd $TMP/daily-*/

# 4. Restore SQLite
docker cp 02_n8n_db.sqlite n8n-n8n-1:/home/node/.n8n/database.sqlite

# 5. Restart
cd /docker/n8n && docker compose up -d

Alternative: bei komplett neuem Container — Workflow-JSON aus 02_n8n_workflows.json via API einspielen:


N8N_KEY=$(cat /root/.secrets/n8n_api_key.txt)
# Für jedes workflow in JSON:
jq -c '.data[]' 02_n8n_workflows.json | while read wf; do
  curl -s -X POST http://localhost:5678/api/v1/workflows \
    -H "X-N8N-API-KEY: $N8N_KEY" -H "Content-Type: application/json" \
    -d "$wf"
done

Dann mit gen_tools.py && gen_crons.py && gen_telegram.py alles frisch deployen.

---

Szenario D: Ganze Maschine kaputt (Hostinger VPS down / hin)

Symptom: SSH unreachable, Hostinger-Panel zeigt "stopped/failed".

Recovery (~4h):


# 1. Neue VPS bei Hostinger provisionieren (Ubuntu 24, gleiche Specs)
# 2. SSH-Key hinterlegen, root-Login

# 3. System prep
apt update && apt install -y docker.io docker-compose-plugin git mysql-client unzip curl jq gpg
systemctl enable docker && systemctl start docker

# 4. Backup-Wiederherstellung aus Hostinger-Snapshot (über Panel) ODER aus alter VPS falls erreichbar
# Aktuell (ohne Off-Site):
#   Manuelles Holen vom alten Server (wenn noch erreichbar) oder aus lokalem Clone

# 5. Daily-Backup extrahieren (GPG-entschlüsseln mit Key 1 Private Key)
gpg --decrypt /backup/daily-LATEST.tar.gz.gpg | tar -xz -C /root

# 6. Docker-Compose-Stacks wiederherstellen
cd /root/daily-LATEST && tar -xzf 05_docker_compose.tar.gz -C /
for d in /docker/*/; do cd "$d" && docker compose up -d; done

# 7. Perfex-DB reimport (analog Szenario B)
# N8N-DB-Restore (analog Szenario C)

# 8. Secrets entschlüsseln (Key 2)
gpg --decrypt 04_secrets.tar.gz.gpg | tar -xz -C /root/

# 9. Wiki wiederherstellen
git clone 03_wiki.bundle /root/wiki

# 10. DNS auf neue IP umstellen (MANUELL, Chapaty bei Hostinger/Cloudflare)

# 11. SSL neu via NPM/certbot ausstellen (Domains sollten automatisch laufen)

# 12. Smoke-Tests:
#    - curl http://localhost:5678/healthz (N8N)
#    - curl http://localhost:8081 (Perfex)
#    - docker ps (alle Container running?)
#    - Telegram-Bot-Ping: Chapaty sendet "/ping" an @Penelope_bestbuddybot

---

Szenario E: Silent Corruption (Agent lernt falsch, etc.)

Symptom: Ergebnisse werden über Tage/Wochen schlechter, bestimmte Learnings produzieren falsche Outputs.

Recovery (selektiv, 1-2h):


# 1. Identifiziere Problem
#    Welche Learnings verursachen es? → Chapaty-Review in wiki/learnings/

# 2. Backup von vor 4 Wochen holen (monthly)
gpg --decrypt /backup/daily/daily-YYYYMMDD.tar.gz.gpg | tar -xz -C /tmp/oldbak

# 3. NUR wiki/learnings/ aus altem Backup wiederherstellen
cp -r /tmp/oldbak/daily-YYYYMMDD/03_wiki_working/wiki/learnings /root/wiki/

# 4. Git-Commit
cd /root/wiki && git add -A && git commit -m "Rollback learnings to YYYY-MM-DD (silent corruption recovery)"

# 5. Meilisearch reindex
python3 /root/scripts/index_wiki.py

# 6. Test: betroffene Task-Typ nochmal ausführen

DB + Secrets bleiben aus aktuellem Backup, damit keine DSGVO-Daten verloren gehen.

---

Quartalsweiser DR-Test

Chapaty übt jede Quartal auf einer Test-VPS Szenario D (kompletter Maschinen-Recovery). Ziel: Runbook aktuell halten, RPO/RTO verifizieren.

Kontakte im Notfall

Logs beim Recovery