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 Verantwortlichkeitenvaultwarden-restore-test.ps1: erster Mini-Restore-Ablaufvaultwarden-plan.md: konkreter Vaultwarden-Testplanvaultwarden-compose.test.yml: isolierte Testinstanz fuer Vaultwarden- spaeter weitere Tests fuer
giteaundpaperless
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
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.
Status
Aktuell ist hier nur die erste Repo-Vorbereitung angelegt.
- noch kein echter Restore-Lauf
- noch keine Host-Pfade beschrieben
- noch keine Container gestartet
- erster V1-Ablauf ohne
ntfy, mit Bereinigung nach Erfolg
Vor dem ersten echten Testlauf muessen Zielpfade, Quellpfade und Bereinigungsschritte bewusst freigegeben werden.