Micha
6f0e6f0d5a
Erstlauf 2026-06-03 scheiterte mit 503: Redis-Host war noch auf dem produktiven 'nextcloud-redis' statt 'restoretest-nextcloud-redis', und trusted_domains enthielt kein 127.0.0.1 (Nextcloud blockt mit "Access through untrusted domain"). Ursache: das sed-Pattern fuer Redis versuchte den ganzen Array-Block einzeilig zu ersetzen, traf aber das PHP-Mehrzeilenformat nicht. Und das trusted_domains-sed fand das Schliessmuster nicht zuverlaessig. Fix: - Redis-Host separat per sed patchen (nur den 'host'-Wert im Block) - trusted_domains per PHP-CLI rewrite (robuster als sed auf PHP-Arrays) - Fallback auf sed fuer Hosts ohne php Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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 auchborg-ui:/data/borg.dbundborg-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 -
nextcloud-restore-test.sh: Nextcloud-Restore-Job (Scaffold; Erstlauf noch offen) -
nextcloud-compose.test.yml: isolierte Testinstanz fuer Nextcloud inkl. Test-Postgres und Test-Redis -
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
*.shsind die produktive Host-Variante check-restore-freshness.ps1und 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_hostsimborg-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.