Micha/homelab-infra
1
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
Files
207f49f00126e8a3d47ca3feebbf9a1d62c51c76
homelab-infra/docs/RESTORE_MATRIX.md
T
Micha a687d9b73e docs: record redis restore test
2026-06-06 08:11:03 +02:00

26 KiB
Raw Blame History

Restore Matrix - KalliLab CORE

Diese Matrix beschreibt fuer die wichtigsten Dienste:

  • was die fuehrende Restore-Quelle ist
  • welche Pfade oder Dumps relevant sind
  • welche Secrets gebraucht werden
  • wovon der Dienst abhaengt
  • wie ein sinnvoller Smoke-Test aussieht

Sie ist die fachliche Ergaenzung zu docs/DISASTER_RECOVERY.md.

Legende

  • Fuehrende Quelle = die primaere Restore-Wahrheit fuer diesen Dienst
  • Datei-Restore = relevante Verzeichnisse / Volume-Pfade
  • Dump / DB = relevante Dump-Artefakte oder Datenbankabhaengigkeiten
  • Secrets / ENV = Dinge, die vor dem Start wieder da sein muessen
  • Smoke-Test = minimaler Nachweis, dass der Restore wirklich greift

Tier 1 - Kritisch fuer Wiederanlauf

Dienst Fuehrende Quelle Datei-Restore Dump / DB Secrets / ENV Abhaengigkeiten Smoke-Test
Unraid OS Flash Borg-Artefakt + optional Unraid Connect /boot/config aus unraid-flash-config.tar.gz unraid-flash-config.tar.gz, .sha256, Manifest enthaelt sensible Host-Konfiguration, wie Secret-Material behandeln Unraid USB Flash Creator / neuer Boot-Stick Unraid bootet, Array-Zuordnung und Shares sind sichtbar
Traefik Share / Borg /mnt/user/appdata/traefik, besonders dynamic/, letsencrypt, secrets keine eigene DB cloudflare_dns_api_token frontend_net, backend_net https://traefik.kaleschke.info erreichbar, Dashboard ueber Authelia
AdGuard Home Share / Borg /mnt/user/appdata/adguard/conf keine keine zusaetzlichen Repo-Secrets dokumentiert dns_net, frontend_net DNS-Aufloesung funktioniert; Restore-Smoke am 2026-06-06 erfolgreich
Tailscale Share / Borg /mnt/user/appdata/tailscale keine Tailscale-State im Pfad Host-Netz Tailscale verbunden
PostgreSQL 18 Share + Dumps /mnt/user/appdata/postgresql18 (archivierter Rollback-Altstand: /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/postgresql17) postgresql17-globals.sql, postgresql17-mailarchiver.dump, postgresql17-paperless.dump, optional postgresql17-authelia.dump postgres_password.txt, App-Rollen-Passwoerter aus den jeweiligen Stack-ENV/Secret-Dateien backend_net DB startet, Ziel-Datenbanken vorhanden; SHOW data_checksums ist on
Redis 8 Share / Host /mnt/user/appdata/redis; Rollback-Backup unter /mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-<ts> RDB/AOF-Dateien im Datenpfad redis_password.txt backend_net Redis startet, redis_version ist 8.x, Apps verbinden sich; Restore-Smoke am 2026-06-06 erfolgreich
Authelia Borg /mnt/user/appdata/authelia/config, /mnt/user/appdata/secrets/*authelia* Shared PostgreSQL 18, optional Dump postgresql17-authelia.dump JWT/Session/Storage/Postgres-/SMTP-Secret-Dateien PostgreSQL 18, Traefik, GMX SMTP Login-Seite und ForwardAuth funktionieren; SMTP-Notifier startet; aktive Sessions werden nach Restart neu aufgebaut; Restore-Smoke am 2026-06-03 erfolgreich: Config aus Borg, minimale Test-Config, frisches Test-Postgres, HTTP /api/health 200, Report /mnt/user/backups/restore-reports/authelia-2026-06-03.md
Gitea GitHub-Mirror + Gitea-Bundles fuer Repo-Bootstrap, Borg + Dump fuer Gitea-Appstate /mnt/user/services/gitea/data, /mnt/user/backups/git-bundles/gitea gitea.sqlite.dump, Bundle-Report latest-report.md borg_repo_passphrase.txt fuer Restore-Tests; GitHub-Push-Mirror-PAT liegt nur in Gitea-Mirror-Settings Traefik Web-UI erreichbar, Repo sichtbar, SSH-Port reagiert; Bundle laesst sich klonen und git fsck ist sauber; GitHub-Push-Mirror synchronisiert ohne last_error; Mini-Restore nach /mnt/user/backups/restore-lab/gitea am 2026-05-07 erfolgreich validiert
Komodo Borg / Share /mnt/user/appdata/komodo/core, /mnt/user/appdata/komodo/periphery, /mnt/user/services/stacks komodo-mongo.archive.gz falls verifiziert komodo_mongo_password.txt, KOMODO_* Stack ENV Traefik, Mongo, Gitea UI erreichbar, Periphery verbunden
GitOps Host Automation Borg / Git /mnt/user/services/homelab-infra, /mnt/user/services/posture-check keine eigene DB keine Gitea, Komodo, Unraid User Scripts posture-check laeuft vom Host-Pfad und liefert warning_count: 0 im bekannten Uebergangszustand
Vaultwarden Borg + Dump /mnt/user/appdata/vaultwarden vaultwarden.sqlite.dump vaultwarden_admin_token.txt fuer Produktion; Restore-Test nutzt Wegwerf-Admin-Token und borg_repo_passphrase.txt Traefik Login-Seite erreichbar, Tresor-Daten sichtbar; Mini-Restore nach /mnt/user/backups/restore-lab/vaultwarden am 2026-05-07 erfolgreich validiert

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
Paperless-ngx Borg + Dumps /mnt/user/appdata/paperless-ngx/data, /mnt/user/documents/paperless, /mnt/user/documents/paperless/export, /mnt/user/documents/scans_inbox postgresql17-paperless.dump PAPERLESS_DBPASS, PAPERLESS_REDIS, borg_repo_passphrase.txt fuer Restore-Tests PostgreSQL 18, Redis, Traefik Web-UI startet, Dokumente vorhanden; Restore-Test am 2026-05-31 erfolgreich: Borg-Archiv Tägliche-Sicherung-2026-05-31T04:30:13.181, isolierter PostgreSQL-18-/Redis-8-Testpfad, HTTP 200, 32 Dokumente im Test-DB-Check, Report /mnt/user/backups/restore-reports/paperless-2026-05-31.md
Mealie Borg + Dump /mnt/user/appdata/mealie/data, /mnt/user/appdata/mealie/postgres18 (archivierter Rollback-Altstand: /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/mealie-postgres17) mealie.dump mealie_postgres_password.txt mealie-postgres, Traefik UI startet, Rezepte vorhanden
Immich Borg + Dump /mnt/user/photos/immich, /mnt/user/photos/family_archive, /mnt/user/appdata/immich_postgres_vectorchord; archivierter Rollback-Altstand: /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/immich-postgres-pgvecto-rs immich.dump; nach VectorChord braucht ein Restore ein Postgres-Image mit VectorChord IMMICH_DB_PASSWORD, immich_postgres_password.txt, borg_repo_passphrase.txt fuer Restore-Tests immich_postgres, immich_redis, Traefik DB- und UI-Smoke gegen produktives Borg-Archiv am 2026-05-27 erfolgreich validiert; VectorChord-Migration am 2026-05-31: 11977 Assets, 11107 Smart-Search-Zeilen, 7092 Face-Search-Zeilen, vchord 0.4.3, vector 0.8.1, HTTP/API-Smoke 200. Voll-Restore der Foto-Dateien bleibt separater DR-Drill
Mail-Archiver Borg + Shared Dump /mnt/user/appdata/mailarchiver/data-protection-keys postgresql17-mailarchiver.dump MAILARCHIVER_DB_CONNECTION, MAILARCHIVER_AUTH_PASSWORD PostgreSQL 18, Traefik, Authelia Authelia-Weiterleitung greift; nach Login startet die Web-UI und das Archiv laesst sich oeffnen
Nextcloud Borg + Dump /mnt/user/appdata/nextcloud/html, /mnt/user/documents/nextcloud-data, /mnt/user/appdata/nextcloud/postgres18 (archivierter Rollback-Altstand: /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602/nextcloud-postgres17), /mnt/user/appdata/nextcloud/redis nextcloud.dump; Redis-Backup vor Redis-8-Cutover unter /mnt/user/backups/borg/dumps/latest/nextcloud-redis-pre-redis8-<ts> nextcloud_admin_user.txt, nextcloud_admin_password.txt, nextcloud_postgres_password.txt; produktive DB-Rolle laut config.php ist oc_admin nextcloud-postgres, nextcloud-redis, Traefik Web-UI startet, Login funktioniert, Dateien sichtbar; occ status zeigt maintenance: false
Glance Git / Borg-Repo Repo-Konfiguration unter ops/glance/config/glance.yml; keine kritische Datenpersistenz keine GLANCE_IMMICH_API_KEY, GLANCE_ADGUARD_USERNAME, GLANCE_ADGUARD_PASSWORD, GLANCE_SPEEDTEST_API_KEY Traefik, Authelia, optional interne API-Ziele Dashboard startet, Widgets laden, Docker-Status laeuft nur ueber glance-docker-socket-proxy
ntfy Borg / Share /mnt/user/appdata/ntfy keine keine besonderen Secret-Dateien dokumentiert Traefik UI und Push-Endpunkt erreichbar
Paperless-GPT Borg / Share /mnt/user/appdata/paperless-gpt keine eigene DB PAPERLESS_API_TOKEN, OPENAI_API_KEY Traefik, Paperless, OpenAI API UI startet, Konfiguration vorhanden; LLM-Provider zeigt openai / gpt-5.4-mini

Tier 3 - Rebuildbar / Sekundaer

Dienst Fuehrende Quelle Datei-Restore Dump / DB Secrets / ENV Abhaengigkeiten Smoke-Test
Borg UI Borg + Dump /mnt/user/appdata/borg-ui/data borg-ui.sqlite Borg-Repo-Creds in /data Traefik UI startet, Repo-Verbindung bekannt
Filebrowser Share / Fresh + Dump /mnt/user/appdata/filebrowser filebrowser.bolt.dump filebrowser_admin_password.txt bei Fresh-Rebuild Traefik, Authelia UI startet, Admin-User vorhanden
Glances Rebuildbar kein kritischer Zustand keine keine Traefik, Authelia UI startet
Scrutiny Teilweise rebuildbar /mnt/user/appdata/scrutiny falls gewuenscht InfluxDB bewusst nicht Teil des Critical-Scope keine Traefik, Authelia UI startet, Laufwerke sichtbar
Speedtest Tracker Share + Dump /mnt/user/appdata/speedtest-tracker/config speedtest-tracker.sqlite.dump APP_KEY, ADMIN_PASSWORD Traefik, Authelia UI startet
BentoPDF Rebuildbar keine kritische Persistenz; alte Stirling-PDF-Daten unter /mnt/user/appdata/stirling-pdf bis zur Abnahme behalten keine keine separaten Secret-Dateien dokumentiert Traefik, Authelia UI startet, PDF-Tools verfuegbar, Office-Konvertierung ueber HTTPS funktioniert
Grafana historischer Altstand /mnt/user/appdata/grafana grafana.sqlite grafana_admin_password.txt, grafana_influxdb_token.txt nicht aktiv Compose-Pfad aus aktivem Repo entfernt; nur ueber Git-Historie wiederherstellen, falls ein Rollback wirklich noetig ist
InfluxDB 3 Core historischer Altstand / Datenuebernahme /mnt/user/appdata/influxdb3/data, /mnt/user/appdata/influxdb3/plugins dateibasierter Object Store influxdb3_admin_token.json monitoring-influxdb3-core Datenpfad wird vom Monitoring-Zielstack weitergenutzt und darf nicht blind geloescht werden
Loki / Alloy historischer Altstand /mnt/user/appdata/loki/config, /mnt/user/appdata/loki/data, /mnt/user/appdata/alloy/config keine primaere DB; Loki-Dateispeicher war transient keine zusaetzlichen Secrets nicht aktiv Compose-Pfad aus aktivem Repo entfernt; aktuelle Logsammlung laeuft ueber monitoring-loki/monitoring-promtail
Monitoring Stack Rebuild + named volumes + InfluxDB-Appdata prometheus_data, loki_data, promtail_positions, grafana_data; InfluxDB unter /mnt/user/appdata/influxdb3/data und /mnt/user/appdata/influxdb3/plugins; Provisioning aus monitoring/grafana/provisioning Prometheus-TSDB, Loki-Dateispeicher und InfluxDB-Dateistore; Diagnose-/Langzeitdaten, keine Tier-1-Restore-Quelle monitoring_grafana_admin_password.txt, monitoring_grafana_influxdb_token.txt, influxdb3_admin_token.json monitoring_net, monitoring_influx_lan, frontend_net, Traefik, Authelia, Docker socket read-only fuer Promtail, Host-Mounts fuer node-exporter/cAdvisor https://monitoring.kaleschke.info leitet zu Authelia; Prometheus Targets sind up; Grafana-Datasources Prometheus, Loki und InfluxDB 3 Core funktionieren
Hermes Agent VM-seitig offen /mnt/user/appdata/hermes-agent/data, /mnt/user/appdata/hermes-agent/ssh keine eigene DB Host-.env fuer Provider-/API-/Home-Assistant-Tokens, hermes_runner_id_ed25519, HERMES_DASHBOARD_HOST separate Hermes-VM/Runner, Traefik, Authelia, hermes_net NAS-Stack nicht starten, solange Runner-VM und echte .env fehlen
ddns-updater Rebuildbar geringe Persistenzrelevanz keine Provider-Zugang ueber Stack ENV Internetzugang Update-Job laeuft

Dumps und Restore-Artefakte

Aktuell relevante Dump-Artefakte unter /mnt/user/backups/borg/dumps/latest:

  • postgresql17-globals.sql
  • postgresql17-mailarchiver.dump
  • postgresql17-paperless.dump
  • postgresql17-authelia.dump (optional / wenn vorhanden)
  • mealie.dump
  • immich.dump
  • nextcloud.dump
  • gitea.sqlite.dump
  • vaultwarden.sqlite.dump
  • speedtest-tracker.sqlite.dump
  • filebrowser.bolt.dump
  • borg-ui.sqlite
  • grafana.sqlite
  • unraid-flash-config.tar.gz plus unraid-flash-config.tar.gz.sha256 und Manifest
  • Monitoring-Stack: keine verpflichtenden Dump-Artefakte; Prometheus/Loki/Grafana named volumes sind Diagnose-/Dashboard-Zustand, keine primaere Restore-Quelle.
  • komodo-mongo.archive.gz (noch gesondert verifizieren)

Die Dump-Erzeugung ist host-seitig ueber ops/borg-ui/scripts/pre-backup-dumps.sh vorgesehen.

PostgreSQL 18 Restore- und Rollback-Regeln

  • PostgreSQL-18-Container verwenden das Docker-Image-Layout mit Mount auf /var/lib/postgresql und PGDATA=/var/lib/postgresql/18/docker.
  • Die alten PostgreSQL-17-Datenpfade wurden nach Burn-in am 2026-06-02 aus den aktiven Appdata-Pfaden entfernt und unter /mnt/user/appdata/_archive/pg18-immich-rollback-volumes-20260602 archiviert.
  • Shared-Cluster-Restore: zuerst pg_dumpall --globals-only einspielen, dann die einzelnen Custom-Format-Dumps per pg_restore. Der Bootstrap-Rollenkonflikt fuer mailarchiver ist benign, solange CREATE ROLE mailarchiver; gezielt ausgelassen und das folgende ALTER ROLE mailarchiver ... eingespielt wird.
  • Nextcloud-Restore: vor dem Dump occ maintenance:mode --on, nach erfolgreichem Restore und occ status wieder occ maintenance:mode --off. Die Rolle oc_admin muss mit dem in config.php hinterlegten DB-Passwort existieren.
  • Rollback: betroffene App(s) und DB stoppen, archivierten Altstand zurueck an den frueheren Datenpfad verschieben, Compose auf das vorherige PostgreSQL-17-Image und den alten Datenpfad zuruecksetzen, dann DB und App wieder starten.

Praktische Restore-Regeln

  • Nicht mehrere kritische Dienste gleichzeitig restaurieren.
  • Erst die Abhaengigkeiten wiederherstellen, dann die App.
  • Bei Unsicherheit zuerst in Testpfade oder Testinstanzen pruefen.
  • Der minimale Erfolg ist nicht "Container startet", sondern "fachlicher Smoke-Test gelingt".

Validiertes Restore-Lab-Muster

  • Restore-Quelle bleibt das produktive Borg-Repo
  • Testziel liegt unter /mnt/user/backups/restore-lab/<dienst>
  • Reports liegen unter /mnt/user/backups/restore-reports
  • Borg-Zugriff kann ueber den vorhandenen borg-ui-Container laufen
  • Borg-Passphrasen fuer Restore-Tests sollten aus Host-Secret-Dateien kommen, nicht aus UI-Interna
  • Testinstanzen bekommen keine produktive Domain und keine Traefik-Route

Restore-Test-Reifegrad

Stand 2026-06-06. Pro Dienst auf einen Blick: Wurde der Restore schon einmal real getestet?

Dienst Tier Letzter Restore-Test Typ Naechster Lauf
Vaultwarden 1 2026-05-07 File + Container + HTTP monatlich (1. Sa)
Gitea 1 2026-05-07 File + Container + HTTP + TCP monatlich (3. Sa)
Authelia 1 2026-06-03 Config + Validate + HTTP Health zweimonatlich (2. Sa gerade Mon.)
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 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 2026-06-06 Config + Container + HTTP 401 + DNS + Filter-Count quartalsweise oder nach DNS-Aenderungen
Tailscale 1 - noch kein Test -
PostgreSQL 18 Cluster 1 2026-06-03 globals + 5 per-DB dumps, 290 Tabellen gesamt quartalsweise
Redis 8 1 2026-06-06 Pre-Cutover-Artefakt + Container + PING + INFO + DBSIZE quartalsweise oder vor/nach Redis-Major-Aenderungen
Komodo Mongo Daten 1 2026-06-03 mongorestore --archive --gzip, 86904 docs quartalsweise
Nextcloud 2 2026-06-03 File + Dump + Container + HTTP 200 + occ status + Table-Count (126) quartalsweise
Mealie 2 2026-06-03 File + Dump + Container + HTTP + Recipe-Count (3) quartalsweise
Mail-Archiver 2 2026-06-03 Keys + 645M Dump + Container + HTTP 200 quartalsweise
Glance 2 - rebuildbar, kein Test noetig -
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)

Stand 2026-06-06. 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. Tailscale - State-/Reconnect-Pfad dokumentiert testen

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

Validierungsergebnis 2026-06-06: Automatisierter Test ops/restore-tests/adguard-restore-test.sh auf Unraid erfolgreich ausgefuehrt. Report: /mnt/user/backups/restore-reports/adguard-2026-06-06.md. Getestet wurden Borg-Extract der Config, AdGuardHome.yaml-Struktur, isolierter Testcontainer restoretest-adguard auf localhost-Ports, HTTP /control/status = 401, DNS-Smoke git.kaleschke.info -> 192.168.178.58, 7 Filterlisten-Eintraege. Testdaten wurden nach Erfolg bereinigt.

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

Automatisierter Test:

/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh adguard

Manuelle 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. 15353): 
    ports:
  - "127.0.0.1:15353:53/udp"
  - "127.0.0.1:13001:80/tcp"
volumes:
  - /mnt/user/backups/restore-lab/adguard/conf:/opt/adguardhome/conf
  4. http://127.0.0.1:13001/control/status erreichbar (200, 401 oder 403 sind fuer den Smoke ausreichend)
  5. DNS-Aufloesung: dig @127.0.0.1 -p 15353 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)

Validierungsergebnis 2026-06-06: Automatisierter Test ops/restore-tests/redis-restore-test.sh auf Unraid erfolgreich ausgefuehrt. Report: /mnt/user/backups/restore-reports/redis-2026-06-06.md. Getestet wurde das Pre-Cutover-Artefakt /mnt/user/backups/borg/dumps/latest/shared-redis-pre-redis8-20260531-185011 in einer isolierten Redis-8.8-Testinstanz auf 127.0.0.1:16379. Ergebnis: PING = PONG, redis_version = 8.8.0, AOF aktiv (1), DBSIZE = 1. Produktiver Port und produktiver Datenpfad wurden nicht genutzt.

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

Automatisierter Test:

/mnt/user/services/homelab-infra/ops/restore-tests/run-restore-checks.sh redis

Manuelle 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): 
    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.

Reference in New Issue View Git Blame Copy Permalink