schedule.md: Intervalle und Verantwortlichkeiten
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
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
Bash-Dispatcher und Bash-Restore-Jobs am 2026-05-07 erfolgreich hostseitig verifiziert
Restore-Lab und Report-Pfade auf dem Host angelegt
V1-Ablauf weiter ohne ntfy, mit Bereinigung nach Erfolg
naechster grosser Kandidat ist ein erneuter Immich-Lauf nach VectorChord-Migration mit Zeitmessung; danach in die Rotation aufnehmen

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