Files
homelab-infra/ops/restore-tests/schedule.md
T

99 lines
1.9 KiB
Markdown

# Restore Test Schedule
## Ziel
Regelmaessige Restore-Tests mit wenig Handarbeit und klaren Nachweisen.
## Intervalle
Woechentlich:
- Backup-/Dump-Frische pruefen
- keine echten Restore-Container starten
- pruefen:
- Dump-Dateien vorhanden
- Dump-Dateien nicht zu alt
- letzte Reports vorhanden
Monatlich:
- `vaultwarden` Mini-Restore
- `gitea` Mini-Restore, versetzt zum Vaultwarden-Lauf
Alle 2 Monate:
- `paperless` Mini-Restore
Quartalsweise:
- Restore-/DR-Sanity-Check
- pruefen:
- Restore-Lab-Struktur
- Reports
- Skripte und Pfade
- Doku noch passend
Spaeter:
- `immich` als eigener Sprint
## Konkreter Kalender
- Jeden Montag, 06:30:
- `check-restore-freshness.ps1`
- Jeden 1. Samstag im Monat, 07:00:
- `vaultwarden`
- Jeden 3. Samstag im Monat, 07:00:
- `gitea`
- Jeden 2. Monat am 2. Samstag, 08:00:
- `paperless`
- Quartalsweise am 1. Werktag des Quartals:
- DR-/Restore-Sanity-Check
## Betriebsmodus
- V1:
- Jobs laufen hostseitig manuell oder per User Script
- `ntfy` ist optional und folgt nach stabiler Basis
- Hermes wertet spaeter nur Reports aus
- V2:
- fester Host-Schedule
- `ntfy` bei Erfolg/Fehler
- Hermes erzeugt Zusammenfassungen und Overviews
## Automatisierung
Automatisch:
- Testpfad vorbereiten
- Restore in `restore-lab`
- Testcontainer `restoretest-*` starten
- Smoke-Test ausfuehren
- Markdown-Report schreiben
- `ntfy` Erfolg/Fehler senden
- alte Testartefakte bereinigen
Manuell:
- neue Testfaelle einfuehren
- riskante oder produktionsnahe Sondertests
- Aenderungen an Restore-Logik
- Freigabe fuer den ersten echten Restore je Dienst
## Ablage
- Quelle: `/mnt/user/backups/borg`
- Restore-Lab: `/mnt/user/backups/restore-lab`
- Reports: `/mnt/user/backups/restore-reports`
## Erfolgsregel
Ein Test gilt erst dann als erfolgreich, wenn:
- Restore abgeschlossen ist
- Testcontainer startet
- definierter Smoke-Test erfolgreich ist
- Report geschrieben wurde
Nur "Container laeuft" reicht nicht.