Files
homelab-infra/ops/restore-tests
Micha c922d1f241 docs(restore): finalize audit - handbook update, reifegrad matrix, backlog
Schliesst das Restore-Skills-Audit 2026-06-02/03 ab:

- RESTORE_HANDBOOK.md auf Stand 2026-06-03: alle 6 verifizierten Tests
  (Vaultwarden, Gitea, Paperless, Immich, Authelia, Komodo-Bootstrap)
  dokumentiert, Frequenz-Tabelle aktualisiert, Betriebsmodus auf V1+
  (mit ntfy), Schnellstart um Immich/Authelia/Komodo ergaenzt,
  Report-Aufbewahrungsregel dokumentiert, Ausbaustufen priorisiert.

- RESTORE_MATRIX.md: neue Sektion "Restore-Test-Reifegrad" mit
  Uebersichtstabelle (pro Dienst: Tier, letzter Test, Typ, naechster
  Lauf) und priorisierter Kandidatenliste fuer fehlende Tests.

- Gitea-Restore: SSH-Check im Report korrekt als "TCP connect only"
  benannt statt "SSH port open" (war Audit-Finding M3).

- AUDIT_2026-05-25_TODO.md: Restore-Audit-Backlog ergaenzt mit den
  verbleibenden 8 offenen Punkten (Nextcloud, Shared PG18, Komodo-Mongo,
  Mailarchiver, Mealie, Traefik, Negativ-Test, E2E-DR-Drill).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-03 09:31:19 +02:00
..

Restore Tests

Kontrollierte Restore-Tests fuer homelab-infra.

Ziel:

  • Backups durch echte Test-Restores verifizieren
  • produktive Pfade nicht beschreiben
  • Testlaeufe spaeter weitgehend automatisieren

Grundregeln

  • Restore-Quelle bleibt im Backup-Bereich, z. B. /mnt/user/backups/borg
  • Test-Restores laufen nur in /mnt/user/backups/restore-lab
  • Reports landen in /mnt/user/backups/restore-reports
  • Test-Container nutzen das Praefix restoretest-
  • keine produktiven Volumes schreibend mounten
  • keine produktiven Domains fuer Testinstanzen uebernehmen

Geplante Struktur

  • schedule.md: Intervalle und Verantwortlichkeiten
  • common.sh: gemeinsame Helfer fuer Borg-Lookup, Borg-Extract und Compose-Cleanup; prueft vor Borg-Operationen auch borg-ui:/data/borg.db und borg-ui:/local/secrets/borg_repo_passphrase.txt
  • vaultwarden-restore-test.ps1: erster Mini-Restore-Ablauf
  • vaultwarden-restore-test.sh: hosttauglicher Vaultwarden-Restore-Job
  • vaultwarden-plan.md: konkreter Vaultwarden-Testplan
  • vaultwarden-compose.test.yml: isolierte Testinstanz fuer Vaultwarden
  • gitea-restore-test.ps1: Gitea-Mini-Restore-Ablauf
  • gitea-restore-test.sh: hosttauglicher Gitea-Restore-Job
  • gitea-plan.md: konkreter Gitea-Testplan
  • gitea-compose.test.yml: isolierte Testinstanz fuer Gitea
  • paperless-restore-test.ps1: Paperless-Mini-Restore-Ablauf
  • paperless-restore-test.sh: hosttauglicher Paperless-Restore-Job
  • paperless-plan.md: konkreter Paperless-Testplan
  • paperless-compose.test.yml: isolierte Testinstanz fuer Paperless inkl. Test-Postgres und Test-Redis
  • immich-restore-test.ps1: Immich-Mini-Restore-Ablauf als Plan-/Windows-Scaffold
  • immich-restore-test.sh: hosttauglicher Immich-Restore-Job, erster echter Lauf noch offen
  • immich-plan.md: konkreter Immich-Testplan
  • immich-runbook.md: Operator-Runbook fuer den ersten Immich-Lauf
  • immich-compose.test.yml: isolierte Testinstanz fuer Immich inkl. VectorChord/pgvector-Test-Postgres und Test-Redis
  • authelia-restore-test.sh: Authelia-Restore-Job (Config-Smoke; Erstlauf 2026-06-03 erfolgreich)
  • authelia-compose.test.yml: isolierte Testinstanz fuer Authelia inkl. Test-Postgres, Filesystem-Notifier (kein echter SMTP-Versand)
  • authelia-plan.md: konkreter Authelia-Testplan
  • authelia-runbook.md: Operator-Runbook fuer den ersten Authelia-Lauf
  • check-restore-freshness.ps1: woechentlicher Frische-Check fuer Dumps und Reports
  • run-restore-checks.ps1: einfacher Dispatcher fuer Restore-Jobs
  • check-restore-freshness.sh: hosttauglicher Frische-Check
  • run-restore-checks.sh: hosttauglicher Dispatcher
  • common.sh: gemeinsame Host-Helferfunktionen
  • automation-plan.md: Host-Job- und Automatisierungsmodell

Automatisierungsmodell

  • Ausfuehrung: Unraid User Script / Host-Job
  • Logik: Repo-Skripte in diesem Verzeichnis
  • Ergebnis: Markdown-Report
  • Meldung: ntfy
  • Hermes: optional nur fuer Zusammenfassung und Auswertung

Wichtig:

  • die Bash-Skripte *.sh sind die produktive Host-Variante
  • check-restore-freshness.ps1 und die *.ps1-Dateien bleiben als lokale Plan-/Hilfsvariante nutzbar
  • im Windows-Clone fehlen die /mnt/user/...-Pfade naturgemaess

Validiertes Grundmuster

Stand nach dem ersten echten Vaultwarden-Test:

  • Borg-Quelle bleibt das produktive Remote-Repo bei Hetzner
  • Borg-Zugriff laeuft praktisch ueber den vorhandenen borg-ui-Container
  • SSH-Trust wird ueber known_hosts im borg-ui-Container hergestellt
  • die Borg-Passphrase kommt fuer Restore-Tests aus einer Host-Secret-Datei
  • Restore-Ziel liegt immer getrennt unter /mnt/user/backups/restore-lab
  • Reports liegen unter /mnt/user/backups/restore-reports
  • Testinstanzen bekommen keine produktive Domain und keine Traefik-Route

Das ist das bevorzugte Muster fuer weitere dateibasierte Restore-Tests wie gitea.

Fuer datenbankgestuetzte Dienste wie paperless kommt zusaetzlich ein isolierter Dump-Restore in Test-Postgres dazu.

Status

Aktuell ist das erste validierte Muster vorhanden.

  • echter Vaultwarden-Restore am 2026-05-07 erfolgreich verifiziert
  • echter Gitea-Restore am 2026-05-07 erfolgreich verifiziert
  • echter Paperless-Restore am 2026-05-07 erfolgreich verifiziert
  • Immich-Restore-Test am 2026-05-27 erfolgreich verifiziert; Test-Postgres wurde nach der VectorChord-Migration am 2026-05-31 auf das produktive Immich-Postgres-Image umgestellt
  • Authelia-Restore-Smoke am 2026-06-03 erfolgreich verifiziert; bewusst ohne produktiven Dump-Restore wegen Storage-Encryption-Key-Kopplung
  • Bash-Dispatcher und Bash-Restore-Jobs am 2026-05-07 erfolgreich hostseitig verifiziert
  • Restore-Lab und Report-Pfade auf dem Host angelegt
  • ntfy-Wrapper ist fuer Host-Jobs verfuegbar
  • naechste grosse Kandidaten sind Nextcloud, Mailarchiver, Mealie und Komodo-Mongo-Daten-Restore

Vor dem ersten echten Testlauf je neuem Dienst muessen Zielpfade, Quellpfade und Bereinigungsschritte bewusst freigegeben werden.