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

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.