backup: windows image baseline for baerchen

docs/RESTORE_MATRIX.md

@@ -40,6 +40,14 @@ Sie ist die fachliche Ergaenzung zu `docs/DISASTER_RECOVERY.md`.
 
 ---
 
+## Workstations
+
+| System | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
+|---|---|---|---|---|---|---|
+| `baerchen` Windows 11 | Veeam Agent Image auf Unraid-SMB | `/mnt/user/backups/windows-images/baerchen/` bzw. `\\kallilabcore\backups\windows-images\baerchen` | Veeam Restore Points im Zielordner; erster Full-Lauf 2026-06-05, GUI-Groesse 53,8 GB, Dauer 0:11:31, MetaCheck 0 Fehler/0 Warnungen | SMB-User `micha`; Veeam Job Encryption Password nur noetig, falls Storage Encryption spaeter aktiviert wird; BitLocker-Recovery-Key erst noetig, wenn BitLocker spaeter aktiviert wird | Veeam Recovery USB `VEEAMRE`, SMB auf `kallilabcore`, AdGuard/DNS oder direkte IP | Von `VEEAMRE` booten, SMB-Ziel oeffnen, Restore Point anzeigen, vor echtem Restore abbrechen; Runbook `ops/windows-reinstall/docs/windows-image-backup-baseline.md` |
+
+---
+
 ## Tier 2 - Wichtige Anwendungen
 
 | Dienst | Fuehrende Quelle | Datei-Restore | Dump / DB | Secrets / ENV | Abhaengigkeiten | Smoke-Test |
@@ -127,7 +135,7 @@ Die Dump-Erzeugung ist host-seitig ueber `ops/borg-ui/scripts/pre-backup-dumps.s
 
 ## Restore-Test-Reifegrad
 
-Stand 2026-06-03. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?
+Stand 2026-06-05. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?
 
 | Dienst | Tier | Letzter Restore-Test | Typ | Naechster Lauf |
 |---|---|---|---|---|
@@ -137,7 +145,7 @@ Stand 2026-06-03. Pro Dienst auf einen Blick: Wurde der Restore schon einmal rea
 | Komodo Bootstrap | 1 | 2026-05-30 | Compose + Mongo + HTTP | quartalsweise |
 | Paperless | 2 | 2026-05-31 | File + Dump + Container + HTTP + Doc-Count | zweimonatlich (2. Sa ungerade Mon.) |
 | Immich | 2 | 2026-05-27 | Dump + Container + HTTP + Asset-Count | quartalsweise (2. So Feb/Mai/Aug/Nov) |
-| Unraid OS Flash | 1 | - | noch kein Test | - |
+| Unraid OS Flash | 1 | 2026-06-05 (Artefakt-Validierung) | sha256 OK + 390 Eintraege + 8 Kern-Configs vorhanden (`ops/maintenance/check-unraid-flash-backup.sh`); **physischer Ersatzstick-Boot-Test weiter offen** | Stick-Boot-Test nach Bedarf |
 | Traefik | 1 | 2026-06-03 | Config + LE-State + File-Provider + Ping 200 | quartalsweise |
 | AdGuard Home | 1 | - | noch kein Test | - |
 | Tailscale | 1 | - | noch kein Test | - |
@@ -151,13 +159,157 @@ Stand 2026-06-03. Pro Dienst auf einen Blick: Wurde der Restore schon einmal rea
 | ntfy | 2 | - | rebuildbar, kein Test noetig | - |
 | Borg UI | 3 | - | rebuildbar | - |
 | Filebrowser | 3 | - | rebuildbar | - |
+| baerchen Windows Image | Workstation | 2026-06-05 | Full-Backup geschrieben; Recovery USB + SMB-Mount noch offen | Recovery-USB-Test |
 
 ---
 
 ## Naechste Restore-Test-Kandidaten (priorisiert)
 
-1. **Shared PostgreSQL 18 Cluster** - globals + per-DB-Dumps, Bootstrap-Konflikt `mailarchiver`
-3. **Komodo Mongo Daten** - echtes `mongorestore` aus `komodo-mongo.archive.gz` (Quelle fuer `KOMODO_*`-Stack-ENVs im DR)
-4. **Mailarchiver** - Tier 2, shared Postgres + Authelia ForwardAuth
-5. **Mealie** - Tier 2, eigene Postgres
-6. **Traefik** - Tier 1, aber komplex (dynamic/, LE-State, CF-Token-Mount)
+Stand 2026-06-05. Die frueheren Kandidaten (Shared PG18, Komodo Mongo, Mailarchiver, Mealie, Traefik)
+wurden alle am 2026-06-03 abgeschlossen und sind in der Reifegrad-Tabelle belegt.
+
+Verbleibende offene Restore-Pfade ohne vollstaendigen Test:
+
+1. **Unraid OS Flash** - Artefakt-Validierung am 2026-06-05 erfolgreich (siehe Reifegrad-Tabelle und Runbook unten); offen bleibt nur der **physische Ersatzstick-Boot-Test**.
+2. **AdGuard Home** - Config-Restore in Testpfad oder Wegwerf-Instanz pruefen
+3. **Tailscale** - State-/Reconnect-Pfad dokumentiert testen
+4. **Redis 8 (Shared)** - Restore aus Datenpfad oder Pre-Cutover-Backup in isolierter Testinstanz pruefen
+
+---
+
+## Restore-Test-Runbooks (Entwurf)
+
+Diese Abschnitte sind vorbereitete Checklisten fuer die noch untesteten Restore-Pfade.
+Sie sind **nicht** als produktive Anleitungen zu verwenden, bevor ein erster Testlauf
+die konkreten Artefaktnamen und Pfade bestaetigt hat.
+
+### Unraid OS Flash
+
+**Voraussetzungen:**
+- Borg-Artefakt `unraid-flash-config.tar.gz` und `unraid-flash-config.tar.gz.sha256` unter `/mnt/user/backups/borg/dumps/latest` oder im Hetzner-Borg-Repo verfuegbar
+- Neuer leerer USB-Stick (Empfehlung: 16 GB, USB 2.0 kompatibel)
+- Unraid USB Flash Creator oder manueller Restore-Pfad
+- Offline-gesicherte Borg-Passphrase verfuegbar
+
+**Checkliste Artefakt-Validierung (ohne produktiven Stick):**
+
+Automatisiert via Repo-Skript `ops/maintenance/check-unraid-flash-backup.sh`
+(read-only, keine Extraktion). Manuelle Einzelschritte:
+
+1. SHA256-Pruefung: `sha256sum -c unraid-flash-config.tar.gz.sha256`
+2. Artefakt-Inhalt pruefen: `tar -tzf unraid-flash-config.tar.gz | head -40` — erwartet `config/` als Prefix
+3. Kern-Configs vorhanden: `super.dat`, `disk.cfg`, `ident.cfg`, `share.cfg`, `network.cfg`, `docker.cfg`, `go`, `domain.cfg`
+4. Keine produktiven Konfigurationspfade (z. B. `config/ssh/`) ausserhalb des Test-Environments extrahieren
+5. Manifest-Datei auf Vollstaendigkeit pruefen
+
+**Validierungsergebnis 2026-06-05 (read-only per SSH):** Artefakt frisch
+(2026-06-05 04:00, ~16 h alt beim Test), `sha256sum -c` = OK, 390 Eintraege,
+alle 8 Kern-Configs vorhanden. Das Archiv enthaelt erwartungsgemaess
+Secret-Material (SSH-Host-Keys, Tailscale-State, `passwd`/`shadow`/`smbpasswd`,
+`Trial.key`) und ist wie Secret-Backup zu behandeln. Es wurde nichts extrahiert,
+nur Eintragsnamen gelistet. Offen bleibt der physische Ersatzstick-Boot-Test.
+
+**Checkliste vollstaendiger Restore-Test (auf Wegwerf-Stick):**
+
+1. Neuen USB-Stick mit Unraid USB Flash Creator formatieren und Basis-Unraid draufspielen
+2. `config/`-Verzeichnis aus `unraid-flash-config.tar.gz` in den `/boot/config`-Pfad des neuen Sticks extrahieren
+3. Im Testrahmen booten (kein Array starten, keine Shares mounten)
+4. Pruefen: Unraid-Grundkonfiguration (Shares, Hostname, Netzwerk) ist sichtbar
+5. Array-Zuordnung lesbar, ohne Drive-Assigns zu bestaetigen
+
+**Smoke-Test-Kriterium:** Unraid bootet, Hostname ist `Kallilabcore`, Share-Konfiguration ist sichtbar, kein Array gestartet.
+
+**Sonderregel:** Das Artefakt enthaelt Host-Konfiguration und SSH-Keys und ist wie Secret-Material zu behandeln. Nicht auf oeffentlichen oder unverschluesselten Testzielen extrahieren.
+
+---
+
+### AdGuard Home
+
+**Voraussetzungen:**
+- Borg-Archiv mit `/mnt/user/appdata/adguard/conf` zugaenglich (produktives Repo oder Teststand)
+- Testpfad unter `/mnt/user/backups/restore-lab/adguard` vorbereitet
+- Docker-Faehigkeit auf dem Testhost oder in der Restore-Lab-Umgebung
+
+**Checkliste:**
+
+1. Borg-Extract des letzten Archivs nach `/mnt/user/backups/restore-lab/adguard/conf`:
+   ```
+   borg extract ::ARCHIV /mnt/user/appdata/adguard/conf
+   ```
+2. Konfigurationsdatei `AdGuardHome.yaml` auf Vollstaendigkeit pruefen (YAML-Syntax valide)
+3. Testcontainer starten (kein produktiver DNS-Port 53, stattdessen z. B. `5353`):
+   ```yaml
+   ports:
+     - "5353:53/udp"
+     - "3001:3000/tcp"
+   volumes:
+     - /mnt/user/backups/restore-lab/adguard/conf:/opt/adguardhome/conf
+   ```
+4. `http://localhost:3001` erreichbar, Login moeglich
+5. DNS-Aufloesung: `dig @127.0.0.1 -p 5353 git.kaleschke.info` gibt plausible Antwort
+6. Testcontainer stoppen und Testpfad aufraeumen
+
+**Smoke-Test-Kriterium:** AdGuard-Web-UI laeuft, DNS-Aufloesung antwortet, Filterlisten sind geladen.
+
+**Keine Secrets:** AdGuard Home verwendet keine dokumentierten Repo-Secrets; Login-Credentials liegen in der `AdGuardHome.yaml` im Borg-Archiv.
+
+---
+
+### Tailscale
+
+**Voraussetzungen:**
+- Borg-Archiv mit `/mnt/user/appdata/tailscale` zugaenglich
+- Testpfad unter `/mnt/user/backups/restore-lab/tailscale` vorbereitet
+- Achtung: Der Tailscale-State ist maschinenspezifisch. Ein Restore auf denselben produktiven Host wuerde die laufende Verbindung verdraengen. Nur auf einem Wegwerf- oder Offline-Host testen.
+
+**Checkliste Artefakt-Validierung (ohne produktiven Host):**
+
+1. Borg-Extract nach `/mnt/user/backups/restore-lab/tailscale`
+2. State-Verzeichnis auf erwartete Dateien pruefen: `tailscaled.state` vorhanden
+3. Dateisystem-Rechte pruefen: `tailscaled.state` muss fuer `root` zugaenglich sein
+
+**Checkliste Reconnect-Test (auf Wegwerf-Host oder VM):**
+
+1. Tailscale-Container mit dem gemounteten State-Pfad starten
+2. `tailscale status` zeigt `Connected` oder den erwarteten Hostnamen
+3. Tailscale-Admin-Konsole (`login.tailscale.com`) zeigt Geraet als `Online`
+4. SSH ueber Tailscale-IP auf den Testhost moeglich
+5. Testcontainer stoppen; Wegwerf-Geraet in der Tailscale-Admin-Konsole entfernen
+
+**Smoke-Test-Kriterium:** Container verbindet sich mit bestehendem Tailscale-Account (kein neues Re-Auth noetig), Tailscale-IP ist erreichbar.
+
+**Hinweis:** Falls der State veraltet ist (Key expired), wird Tailscale einen Re-Auth anfordern. Das ist ein valides Testergebnis und belegt, wie lang der Reconnect-Pfad bei abgelaufenem Key ist.
+
+---
+
+### Redis 8 (Shared)
+
+**Voraussetzungen:**
+- Pre-Cutover-Backup unter `/mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>` vorhanden, oder Borg-Archiv mit `/mnt/user/appdata/redis`
+- Secret-Datei `redis_password.txt` fuer Testinstanz verfuegbar (aus Borg, nicht als Wert dokumentieren)
+- Testpfad unter `/mnt/user/backups/restore-lab/redis` vorbereitet
+
+**Checkliste:**
+
+1. RDB/AOF-Datei aus dem Backup in den Testpfad kopieren:
+   ```
+   cp /mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts>/dump.rdb \
+      /mnt/user/backups/restore-lab/redis/
+   ```
+   (oder Borg-Extract aus dem Appdata-Archiv)
+2. Testcontainer starten (kein produktiver Port 6379, stattdessen z. B. `16379`):
+   ```yaml
+   ports:
+     - "127.0.0.1:16379:6379"
+   volumes:
+     - /mnt/user/backups/restore-lab/redis:/data
+   command: redis-server --requirepass <aus Secret> --appendonly yes
+   ```
+3. Verbindungstest: `redis-cli -p 16379 -a <pass> PING` antwortet `PONG`
+4. Redis-Version pruefen: `redis-cli -p 16379 -a <pass> INFO server | grep redis_version` zeigt `8.x`
+5. Stichprobe Key-Bestand: `redis-cli -p 16379 -a <pass> DBSIZE` zeigt plausible Zahl (nicht 0)
+6. Testcontainer stoppen und Testpfad aufraeumen
+
+**Smoke-Test-Kriterium:** Redis 8 startet mit dem Restore-Datenpfad, `PING` antwortet, `DBSIZE` ist nicht 0.
+
+**Shared Redis Besonderheit:** Shared Redis wird produktiv nur von Paperless genutzt (AOF aktiv). Bei einem echten Restore nach App-Absturz: Erst Redis aus Backup hochziehen, dann Paperless. Nextcloud hat eigene Redis-Instanz ohne Passwort.