homelab-infra/docs/DR_DRILL_2026-06-03.md

DR Tabletop Drill - 2026-06-03

Trockenlauf gegen docs/DISASTER_RECOVERY.md Phase 0 bis 5 plus referenzierte Runbooks (SERVICES_RECOVERY.md, RESTORE_MATRIX.md, SECRETS_MAP.md, RESTORE_HANDBOOK.md, EXTERNAL_DEPENDENCIES.md).

Szenario: Bare-Metal-Ausfall. Unraid-Host und alle lokalen Festplatten sind weg. Operator hat: Laptop, Hetzner-Account, Vaultwarden-Export, Repo-Doku. Soft-Recovery (Host laeuft, Appdata futsch) ist eine Teilmenge dieser Findings.

Methode: kalter Lesetest. Kein Container gestartet, keine Skripte ausgefuehrt. Jeder Befund ist mit Repo-Datei und Zeile belegt. Spekulative "vielleicht unklar"-Befunde sind weggelassen.

Severity:

• CRITICAL - blockiert Wiederanlauf, ohne Workaround nicht loesbar
• HIGH - blockiert eine Phase, Workaround moeglich aber undokumentiert
• MED - kostet Zeit oder fuehrt zu vermeidbarem Fehler
• LOW - Konsistenz / Stil

Zusammenfassung

ID	Phase	Severity	Thema
P0-1	0	HIGH	Brueckenpfad Windows-Clone -> frischer Unraid-Host fehlt
P0-2	0	HIGH	GitHub-Mirror-Zugang im DR ist nicht eigenstaendig dokumentiert
P1-1	1	CRITICAL	Unraid-Flash-Restore: kein dokumentierter Extract-Pfad ohne laufenden Host
P1-2	1	MED	Unraid-OS-Flash-Restore-Test laut Matrix nie real getestet
P2-1	2	HIGH	KOMODO_* externe Operator-Notiz ist Pflichtquelle, Existenz nicht verifizierbar
P2-2	2	HIGH	DR.md Phase 4 vs. SERVICES_RECOVERY.md Bootstrap-Reihenfolge widerspruechlich
P2-3	2	MED	homelab_smtp_password.txt fehlt in DR.md Phase 2.6.1
P2-4	2	MED	n8n_encryption_key.txt fehlt in DR.md Phase 2.6.1
P2-5	2	LOW	Monitoring-/Filebrowser-Secrets fehlen in DR.md Phase 2.6.1
P3-1	3	HIGH	Borg-Client ohne borg-ui-Container ist nicht dokumentiert
P3-2	3	HIGH	Borg-Passphrase-Bootstrap aus Offline-Sicherung nicht als expliziter Schritt
P3-3	3	MED	Hetzner-Maintenance-Key aus Vaultwarden ist Henne-Ei im Bare-Metal
P4-1	4	HIGH	Externe Docker-Netze in DR.md Phase 4 Stufe 1 nicht erwaehnt
P4-2	4	HIGH	Cloudflare-LE-Rate-Limit-Risiko bei verlorenem letsencrypt-State
P4-3	4	MED	traefik/dynamic/* als Phase-4-Pre-Check fehlt in der Reihenfolge
P4-4	4	HIGH	Authelia "frische Postgres ohne Dump"-Pfad nicht beschrieben
P4-5	4	LOW	Gitea in Stufe 2 hinter Postgres ist faktisch nicht noetig (SQLite)
P4-6	4	HIGH	Komodo-Mongo Passwort-Lockout-Risiko bei restauriertem Datadir
P4-7	4	MED	Komodo extra_hosts mit hardgecodeter LAN-IP bricht bei IP-Wechsel
P4-8	4	HIGH	Stack-ENV-Wiederherstellung in Komodo praktisch nur manueller UI-Eintrag
P5-1	5	LOW	Smoke-Tests in Phase 5 weniger streng als RESTORE_MATRIX
P5-2	5	MED	Kein Verifikationspunkt fuer App-zu-DB-Verbindung nach Stack-ENV-Restore
X-1	uebergreifend	HIGH	Nextcloud-Restore-Skript ist da, aber noch nie real ausgefuehrt

Phase 0 - Repo-Zugang

P0-1 (HIGH) - Brueckenpfad Windows-Clone -> frischer Unraid fehlt

docs/DISASTER_RECOVERY.md:88-93 listet als Repo-Quellen: GitHub-Mirror, lokaler Bare-Clone, lokaler Arbeits-Clone. SERVICES_RECOVERY.md:67-68 nennt den lokalen Operator-Clone unter G:\Gitea_Clone\homelab-infra\ als Vorzug.

Luecke: der Pfad "wie kommt der Windows-Clone auf einen frisch installierten Unraid-Host" ist nicht beschrieben. Implizit: SMB-Share, USB-Stick, scp ueber LAN. Aber auf einem frisch aufgesetzten Unraid existiert noch keine funktionierende SMB-Konfiguration; SSH-Key vom Operator-PC ist nicht vorbereitet.

Vorschlag: Zwei Saetze in DISASTER_RECOVERY.md Phase 0 ergaenzen, wie der Operator-Clone konkret zum Host kommt (USB-Stick + mkdir -p /mnt/user/services/homelab-infra && rsync -a aus Operator-Windows-PC, oder direkt vom GitHub-Mirror per git clone https://github.com/... auf dem Unraid-Host).

P0-2 (HIGH) - GitHub-Mirror-Zugang im DR

SECRETS_MAP.md:42 sagt, der GitHub-Push-Mirror-PAT liegt in den Gitea-Mirror-Settings persistent unter /mnt/user/services/gitea/data. EXTERNAL_DEPENDENCIES.md:18 nennt den Mirror als michaelkaleschke-spec/ homelab-infra und betont "privater" Push-Mirror.

Luecke: Wenn der Mirror privat ist, scheitert ein anonymer git clone im DR-Bootstrap. Es gibt keine dokumentierte Notfall-Quelle fuer einen Read-PAT/SSH-Key, der lokal beim Operator (nicht in Gitea, nicht im Repo) verfuegbar ist.

Vorschlag in EXTERNAL_DEPENDENCIES.md: entweder explizit dokumentieren, dass der Mirror lesend Public ist (DR-fit), oder einen Read-PAT in der Vaultwarden-/Offline-Notiz neben der Borg-Passphrase als Bootstrap-Voraussetzung benennen.

Phase 1 - Unraid und Shares

P1-1 (CRITICAL) - Unraid-Flash-Restore ohne laufenden Host

docs/DISASTER_RECOVERY.md:107 sagt: "Primaere lokale/off-site Restore-Quelle fuer die bestehende Flash-Konfiguration ist das Borg-Artefakt unraid-flash-config.tar.gz aus /mnt/user/backups/borg/dumps/latest."

Henne-Ei: der Pfad ist auf den verlorenen Shares oder auf Hetzner. Hetzner- Zugriff braucht einen funktionierenden Linux-Host mit Borg-Client und Passphrase. Im Bare-Metal-Fall ist genau das nicht da. RESTORE_MATRIX.md Tier 1 Zeile Unraid OS Flash (docs/RESTORE_MATRIX.md:29) sagt nur "Unraid USB Flash Creator / neuer Boot-Stick" - das beschreibt die Stick-Erzeugung, nicht den Extract des Borg-Artefakts.

Operativ: Operator braucht einen Laptop mit Borg-Client + Passphrase + SSH-Key fuer die Hetzner-Storage-Box. Das ist eine separat zu pflegende Operator-Workstation-Voraussetzung und ist in keinem Repo-Dokument als DR-Vorbedingung gelistet.

Vorschlag: In EXTERNAL_DEPENDENCIES.md oder DISASTER_RECOVERY.md Abschnitt 3 als Pflichtposten aufnehmen: "Operator-Laptop mit installiertem Borg-Client, SSH-Key fuer Hetzner und Zugriff auf die offline gesicherte Passphrase". Inklusive Test, dass der Operator den Extract tatsaechlich durchfuehren kann.

P1-2 (MED) - Unraid-OS-Flash-Restore-Test nie gelaufen

docs/RESTORE_MATRIX.md:140 Spalte "Letzter Restore-Test" fuer Unraid OS Flash: - (kein Test). Das ist die Grundlage fuer Phase 1 und ist nie als Smoke verifiziert. Empfehlung: einmaliger Test, der die Tar-Archiv-Struktur gegen die erwarteten Flash-Pfade prueft (kein echter Boot-Test noetig).

Phase 2 - Secrets und Stack-ENV

P2-1 (HIGH) - KOMODO_* externe Operator-Notiz als Pflichtquelle

docs/SECRETS_MAP.md:132,138-143 macht den Komodo-Sonderfall klar: die KOMODO_*-Secrets sind aus dem eigenen Mongo-Dump nicht rekonstruierbar, solange Komodo nicht laeuft. Quellen: Vaultwarden ODER externe Notiz.

Im Bare-Metal-Fall ist Vaultwarden in DR.md Phase 4 Stufe 4, Komodo in Phase 4 Stufe 3. Damit ist die externe Operator-Notiz die einzige Pflichtquelle in der Reihenfolge.

Luecke: ob diese Notiz wirklich existiert und die 5 Werte (KOMODO_SECRET_KEY, KOMODO_WEBHOOK_SECRET, KOMODO_JWT_SECRET, KOMODO_MONGO_PASSWORD, KOMODO_PERIPHERY_PASSKEY) enthaelt, ist in keinem Repo-Dokument bestaetigt. Die Borg-Passphrase ist als "Operator-Bestaetigung 2026-05-26" dokumentiert; eine analoge Bestaetigung fuer die KOMODO_*-Notiz fehlt.

Vorschlag: gleiche Form wie Borg-Passphrase - eine Zeile in EXTERNAL_DEPENDENCIES.md "Komodo-Stack-ENV-Notiz offline gesichert, Operator-Bestaetigung YYYY-MM-DD".

P2-2 (HIGH) - Reihenfolgen-Inkonsistenz DR vs. SERVICES_RECOVERY

docs/SERVICES_RECOVERY.md:102 (Stufe C, Komodo-Bootstrap): "Vaultwarden (sobald restauriert), externe Operator-Notiz, oder Komodo-Mongo-Dump (nur wenn Mongo separat bereits gestartet ...)".

docs/DISASTER_RECOVERY.md:247-301 (Phase 4): Stufe 3 = Komodo, Stufe 4 = Vaultwarden.

Wenn ein Leser sich an DR.md Phase 4 haelt, ist Vaultwarden nach Komodo fertig. Aber SERVICES_RECOVERY.md Stufe C setzt Vaultwarden als optionale Vorab-Quelle voraus. Ohne externe Notiz heisst das praktisch: Komodo kann nicht starten. Die Konsequenz steht nirgendwo explizit in DR.md.

Vorschlag: In DISASTER_RECOVERY.md Phase 4 Stufe 3 einen Hinweisblock ergaenzen: "KOMODO_*-Werte muessen vor Stufe 3 aus externer Notiz oder einer in Stufe 2 voraus gezogenen Vaultwarden-Instanz vorliegen. Default- Pfad: externe Notiz."

P2-3 (MED) - homelab_smtp_password.txt fehlt in DR.md 6.1

docs/SECRETS_MAP.md:20 listet /mnt/user/appdata/secrets/ homelab_smtp_password.txt fuer Vaultwarden-SMTP. In DISASTER_RECOVERY.md Abschnitt 6.1 (docs/DISASTER_RECOVERY.md:136-151) ist sie nicht aufgefuehrt. Vaultwarden startet ohne, kann aber keine Einladungs-/ Benachrichtigungs-Mails versenden. Klein, aber unsichtbarer Folgefehler im Familien-Onboarding-Pfad.

P2-4 (MED) - n8n_encryption_key.txt fehlt in DR.md 6.1

docs/SECRETS_MAP.md:58 listet /mnt/user/appdata/secrets/ n8n_encryption_key.txt. In DR.md 6.1 fehlt sie komplett. SECRETS_MAP.md:135 macht die Folgen explizit: "Bei Verlust aller Quellen: n8n startet, aber alle gespeicherten Credentials sind unbrauchbar". Da n8n den GMX-Mail-Workflow fuer das Gitea-Micha/mails-Repo betreibt, ist das ein direkter Workflow-Ausfall.

P2-5 (LOW) - Monitoring-/Filebrowser-Secrets fehlen in DR.md 6.1

docs/SECRETS_MAP.md:53-55: influxdb3_admin_token.json, monitoring_grafana_admin_password.txt, monitoring_grafana_influxdb_token.txt sowie filebrowser_admin_password.txt sind nicht in DR.md 6.1. Tier-3-Apps, Folge ist nur ein UI-Initialisierungs-Schritt nach Wiederanlauf. Keine Critical-Konsequenz, aber Inkonsistenz.

Phase 3 - Borg-Extract

P3-1 (HIGH) - Borg-Client ohne borg-ui-Container

docs/RESTORE_HANDBOOK.md:30-33 sagt explizit: "Borg-Zugriff laeuft ueber den vorhandenen borg-ui-Container".

Im Bare-Metal-Fall ist borg-ui selbst kalt (Tier 3, DR.md Phase 4 Stufe 5). Es gibt keinen dokumentierten Pfad, wie der erste Borg-Extract ohne diesen Container laeuft. Implizite Optionen: nativer Borg auf Unraid (Plugin), docker run --rm borgbackup/borg, oder Operator-Laptop. Keine davon ist benannt.

Vorschlag: In RESTORE_HANDBOOK.md Abschnitt 2 einen "Bare-Metal-Vorlauf" ergaenzen, der den initialen Borg-Extract ohne borg-ui-Container beschreibt - z. B. docker run --rm -v /mnt/user/backups/restore-lab:/restore borgbackup/borg ....

P3-2 (HIGH) - Borg-Passphrase-Bootstrap nicht als expliziter Schritt

docs/DISASTER_RECOVERY.md:68: "Host-Secret-Datei vorhanden und fuer Borg-Zugriff verifiziert; externe Offline-Hinterlegung vom Operator am 2026-05-26 bestaetigt."

Praktisch heisst das: im Bare-Metal-Fall liest der Operator die Passphrase aus einem analogen Medium und tippt sie in den Borg-Client. Das ist ein Bootstrap-Schritt, der nicht als Schritt dokumentiert ist. Er steckt implizit in "extern bestaetigt".

Vorschlag: Ein nummerierter Bullet in DISASTER_RECOVERY.md Phase 3 ("Wenn echte Daten aus Borg benoetigt werden"): "Schritt 1: Borg-Passphrase aus Offline-Sicherung beschaffen. Wert wird nicht in Skripte oder Tickets kopiert; nur in den interaktiven Borg-Aufruf eingegeben."

P3-3 (MED) - Hetzner-Maintenance-Key im Bare-Metal

docs/EXTERNAL_DEPENDENCIES.md:17: "Maintenance-Key liegt in Vaultwarden".

Im Bare-Metal-Bootstrap ist Vaultwarden Phase 4 Stufe 4. Damit ist der Key fuer die initiale Phase-3-Hetzner-Verbindung nicht zugaenglich. Implizit muss er ebenfalls offline gesichert sein (analog Borg-Passphrase).

Vorschlag: gleiche Form wie Borg-Passphrase - eine Operator-Bestaetigung in EXTERNAL_DEPENDENCIES.md, dass der Hetzner-SSH-Key auch ausserhalb von Vaultwarden offline verfuegbar ist. Sonst ist die "Vaultwarden"-Aussage fuer Bare-Metal eine Falle.

Phase 4 - Bootstrap-Reihenfolge

P4-1 (HIGH) - Externe Docker-Netze in DR.md Phase 4 Stufe 1 nicht erwaehnt

docs/SERVICES_RECOVERY.md:82-84 Stufe A schreibt explizit: "Externe Docker-Netze existieren oder werden erzeugt (frontend_net, backend_net). Wenn nicht vorhanden: docker network create --driver bridge frontend_net bzw. ... --internal backend_net."

docs/DISASTER_RECOVERY.md:252-260 Phase 4 Stufe 1 nennt nur Traefik, AdGuard, Tailscale. Kein Hinweis auf externe Netze.

traefik/docker-compose.yml:70-76 deklariert frontend_net, backend_net, monitoring_net als external: true. Ohne vorab erstellte Netze scheitert der erste docker compose up mit "network frontend_net not found".

Vorschlag: In DISASTER_RECOVERY.md Phase 4 vor Stufe 1 einen Vorlauf "Stufe 0 - Docker-Grundlage" einfuegen, der die Netzwerk-Erzeugung wie in SERVICES_RECOVERY.md Stufe A explizit listet.

P4-2 (HIGH) - Cloudflare-LE-Rate-Limit-Risiko

docs/RESTORE_MATRIX.md:30 markiert letsencrypt korrekt als Restore-relevant. docs/DISASTER_RECOVERY.md:240 listet /mnt/user/appdata/traefik/letsencrypt ebenfalls als kritischen Borg-Restore-Pfad.

Luecke: kein Hinweis auf den Praxisfall "LE-State verloren, frischer Acme-Run". Let's Encrypt hat ein Rate-Limit von 50 Zertifikaten/Domain/ Woche und 5 Duplicate-Zertifikate/Woche. Bei einer Multi-Sub-Domain- Konstellation wie *.kaleschke.info (15+ Hostnames) ist das beim hektischen DR-Bootstrap erreichbar.

Vorschlag: In DISASTER_RECOVERY.md Phase 4 Stufe 1 einen Hinweis: "Bei verlorenem oder unklarem acme.json zuerst gegen acme-staging-v02.api.letsencrypt.org ausstellen lassen, erst nach gruenem Smoke auf Production-CA umschalten." Ist eine Praesentations- Aenderung in den Compose-Args, kein neuer Code.

P4-3 (MED) - traefik/dynamic/* als Pre-Check fehlt

docs/DISASTER_RECOVERY.md:357-365 Sektion 10 beschreibt die manuelle Sonderregel fuer traefik/dynamic/*. Korrekt.

docs/DISASTER_RECOVERY.md:252-260 Phase 4 Stufe 1 verweist nicht auf diese Sonderregel. Wer der Reihenfolge folgt und Sektion 10 nicht liest, startet Traefik ohne Middlewares - alle 2FA-Routen brechen still.

Vorschlag: Cross-Reference in Phase 4 Stufe 1: "Vor docker compose up traefik pruefen, dass /mnt/user/appdata/traefik/dynamic/middlewares.yml, tls.yml, dashboards.yml vorhanden sind (Sonderregel Sektion 10)."

P4-4 (HIGH) - Authelia "frische Postgres ohne Dump"-Pfad fehlt

docs/DISASTER_RECOVERY.md:267-275 Phase 4 Stufe 2 startet Postgres und Authelia. Authelia erwartet eine Rolle authelia mit dem Passwort aus authelia_postgres_password.txt. Im Restore-Pfad mit pg_dumpall --globals- only ist die Rolle abgedeckt.

Bei einem fresh-start (keine alten Daten, nur Container hochfahren) ist die Rolle nicht da. Postgres-Image legt sie nicht automatisch an. Authelia schlaegt mit "FATAL: role authelia does not exist" fehl.

Luecke: Der Initialisierungspfad fuer eine frische Postgres ohne pg_dumpall ist in der Doku nicht beschrieben. Im echten DR mit Borg ist das unwahrscheinlich, aber im Soft-Recovery oder Migrations-Drill schon.

Vorschlag: In DISASTER_RECOVERY.md Phase 4 Stufe 2 eine optionale Anweisung: "Falls Postgres frisch ist (kein Dump-Restore), infra/ postgresql17/init/-Skripte oder manuelle CREATE ROLE/CREATE DATABASE- Schritte ergaenzen."

P4-5 (LOW) - Gitea nach Postgres ist faktisch unnoetig

docs/DISASTER_RECOVERY.md:267-275 Phase 4 Stufe 2 ordnet Gitea hinter Postgres ein. Gitea nutzt SQLite (gitea.sqlite.dump), nicht den shared Postgres. Reihenfolge ist nicht falsch, aber irrefuehrend. Nicht kritisch.

P4-6 (HIGH) - Komodo-Mongo Passwort-Lockout-Risiko

ops/komodo/docker-compose.yml:18-20 zeigt: komodo-mongo initialisiert sich bei leerem Datadir mit MONGO_INITDB_ROOT_PASSWORD_FILE aus /mnt/user/appdata/secrets/komodo_mongo_password.txt.

Restore-Fall: Datadir aus Borg restauriert, Secret-Datei aus Borg restauriert - beide aus demselben Snapshot. OK.

Riskanter Fall: Datadir aus Borg, aber Secret-Datei aus einer anderen (neueren oder aelteren) Quelle. Mongo akzeptiert den Login nicht, Komodo laeuft nicht. Lockout. Doku erwaehnt diesen Pin-Punkt nicht.

Vorschlag: Hinweis in DISASTER_RECOVERY.md Phase 4 Stufe 3: "Mongo- Datadir und komodo_mongo_password.txt muessen aus demselben Snapshot kommen. Bei Mismatch: leeren Datadir und Re-Init, dann Daten aus komodo-mongo.archive.gz per mongorestore."

P4-7 (MED) - Hardgecodete LAN-IP in extra_hosts

ops/komodo/docker-compose.yml:50 und :101 haben: "git.kaleschke.info:192.168.178.58".

Bare-Metal-Recovery auf anderer Hardware oder veraenderter LAN-IP fuehrt zu stummem Fehler: Komodo-Core kann Gitea nicht ueber den Override erreichen, faellt auf AdGuard-DNS zurueck (wenn der schon laeuft) oder scheitert.

Vorschlag: kurzer Hinweis in DISASTER_RECOVERY.md Phase 4 Stufe 3: "Bei geaenderter Host-LAN-IP extra_hosts-Werte in ops/komodo/docker-compose. yml vor compose up anpassen oder ueber .env parametrisieren."

P4-8 (HIGH) - Stack-ENV-Wiederherstellung praktisch manuell

docs/DISASTER_RECOVERY.md:188-195 sagt: "Wenn komodo-mongo.archive.gz frisch ist, koennen die Werte beim Komodo-Restart aus dem Dump zurueckgespielt werden, ohne dass jemand sie sieht."

docs/RESTORE_HANDBOOK.md:73-74 und docs/AUDIT_2026-05-25_TODO.md:20 machen den Daten-Mongo-Restore als "erledigt 2026-06-03" sichtbar - aber NICHT als Teil des DR-Bootstraps. Komodo-Bootstrap im Trockenlauf benutzt Wegwerf-Werte.

Praktisch heisst das: Im DR-Bootstrap (Phase 4 Stufe 3) startet Komodo ohne den Mongo-Daten-Restore. Die KOMODO_* kommen aus externer Notiz. Aber die Stack-ENVs fuer paperless/immich/mail-archiver/ speedtest (PAPERLESS_DBPASS etc.) muessen vor Stufe 4 wieder in Komodo eingetragen sein. Wenn der Mongo-Daten-Restore nicht direkt nach Komodo-Start passiert, gehen diese Werte manuell in die Komodo-UI.

Vorschlag: Klarstellung in DISASTER_RECOVERY.md Phase 4 zwischen Stufe 3 und Stufe 4: "Optionaler Mongo-Daten-Restore aus komodo-mongo.archive. gz per ops/restore-tests/komodo-mongo-restore-test.sh-Muster - dann sind alle Stack-ENVs zurueck. Alternativ: Stack-ENVs manuell in Komodo- UI eintragen, Quelle Vaultwarden (sobald Stufe 4 Vaultwarden laeuft - Henne-Ei mit Paperless: Paperless-Start dann erst nach Vaultwarden, nicht parallel)."

Phase 5 - Verifikation

P5-1 (LOW) - Smoke-Tests in DR.md weniger streng als Matrix

docs/DISASTER_RECOVERY.md:337-345 Phase 5.3 sagt z. B. "Vaultwarden startet und ist erreichbar". docs/RESTORE_MATRIX.md:39 sagt: "Login- Seite erreichbar, Tresor-Daten sichtbar". Das zweite ist faktisch der echte Smoke-Test.

Geschmackssache, kein Bug. Empfehlung: DR.md auf die Matrix-Smokes verweisen statt eigene Kurzversion.

P5-2 (MED) - Kein Verifikationspunkt App-zu-DB-Verbindung

docs/DISASTER_RECOVERY.md:337-345 prueft App-Start, nicht DB-Auth- Erfolg. Bei falschem PAPERLESS_DBPASS-Stack-ENV startet Paperless moeglicherweise mit Error-Log und ist via Traefik nicht antwortend - aber das fehlt als Pruefpunkt.

Vorschlag: Phase 5.3 ergaenzen: "Pro App: docker logs <app> zeigt keine password authentication failed/FATAL: role does not exist-Eintraege."

Uebergreifende Findings

X-1 (HIGH) - Nextcloud-Restore-Skript existiert, ist aber ungetestet

ops/restore-tests/nextcloud-restore-test.sh und ops/restore-tests/nextcloud-compose.test.yml existieren im Repo. docs/RESTORE_MATRIX.md:147 Spalte "Letzter Restore-Test" fuer Nextcloud: -, naechster Lauf **hoechste Prio**. docs/AUDIT_2026-05-25_TODO.md:18 fuehrt es als P1 "offen".

Damit ist der echte Tabletop-Gewinn: der Test ist nicht "noch zu bauen", sondern "noch nie ausgefuehrt". Ein bash /mnt/user/services/homelab- infra/ops/restore-tests/nextcloud-restore-test.sh schliesst die letzte Tier-2-Luecke.

Nicht-Findings

Was ich gepruft und als sauber verifiziert habe:

• Referenzierte Skripte existieren alle: pre-backup-dumps.sh, gitea-bundle-mirror.sh, run-restore-checks.sh, komodo-bootstrap-test.sh, posture-check.sh, alle Restore-Test- Skripte fuer Tier-1 und Tier-2.
• Pfadverweise zwischen DR.md, RESTORE_MATRIX.md, SECRETS_MAP.md, SERVICES_RECOVERY.md sind konsistent (Borg-Dumps unter /mnt/user/ backups/borg/dumps/latest, Secrets unter /mnt/user/appdata/secrets).
• Drift-Erkennung Authelia (services/authelia-diff.sh) ist in posture-check integriert (WORKFLOW.md:292).
• GitHub-Mirror-Pfad und Gitea-Bundle-Mirror als Repo-Bootstrap-Quellen sind dreifach abgesichert (lokaler Clone, GitHub, Bundle).
• Tier-1-Postgres-Restore-Drill ist 2026-06-03 erfolgreich gelaufen (AUDIT_2026-05-25_TODO.md:19).
• ops/komodo/docker-compose.yml ist als Recovery-Anker getestet (SERVICES_RECOVERY.md:142-166).
• Borg-Passphrase und Hetzner-Account-Hygiene sind Operator-bestaetigt (AUDIT_2026-05-25_TODO.md:46-47).

Vorschlag fuer Reihenfolge der Folge-Arbeit

1. CRITICAL P1-1 zuerst - Operator-Laptop-Voraussetzung als DR-Pflichtposten dokumentieren. Eine Dokuzeile.
2. HIGH P0-2 + P3-3 - klaeren, ob GitHub-Mirror lesend public ist und wo der Hetzner-Maintenance-Key offline liegt. Zwei Dokuzeilen oder eine echte Setup-Entscheidung.
3. HIGH P2-1 - Operator-Bestaetigung "KOMODO_*-Notiz offline gesichert YYYY-MM-DD" in EXTERNAL_DEPENDENCIES.md ergaenzen (sobald real angelegt).
4. HIGH P4-1 + P4-2 - Vorlauf "Stufe 0 - Docker-Grundlage" und LE-Staging-Hinweis in DR.md Phase 4 einfuegen. Etwa 10 Zeilen Doku.
5. HIGH X-1 - nextcloud-restore-test.sh einmal scharf ausfuehren. Vermutlich ein Vormittag inklusive Report-Review.
6. HIGH P2-2 + P4-8 - Reihenfolgen-Konsistenz Komodo/Vaultwarden in DR.md eindeutig aufloesen.
7. Rest in der Reihenfolge der Tabelle.

Punkte 1-4 sind reine Doku-Arbeit, keine Compose-/Runtime-Aenderung. Punkt 5 ist ein echter Restore-Lauf mit Report. Punkt 6 ist die substanziellste Doku-Aenderung in DR.md.

Reproduktion dieses Drills

Methode: kalter Lesetest gegen
  - docs/DISASTER_RECOVERY.md
  - docs/RESTORE_MATRIX.md
  - docs/SECRETS_MAP.md
  - docs/SERVICES_RECOVERY.md
  - docs/RESTORE_HANDBOOK.md
  - docs/EXTERNAL_DEPENDENCIES.md
  - ops/komodo/docker-compose.yml
  - traefik/docker-compose.yml
Verifizierte Skript-Existenz: ops/borg-ui/scripts/*, ops/restore-tests/*,
  services/posture-check/*
Kein Container gestartet, kein Skript ausgefuehrt, keine produktiven
Pfade beruehrt.