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
• immich Restore-Smoke-Test (DB + UI, ohne produktive Foto-Mounts; Erstlauf 2026-05-27 erfolgreich)
• pruefen:
  • Restore-Lab-Struktur
  • Reports
  • Skripte und Pfade
  • Doku noch passend

Quartals-Belegung:

Quartal	Mini-Restore	Sanity-Fokus
Q1	paperless	Tier-1-Reihenfolge, Posture-Check, Borg-Frische
Q2	immich	Komodo-Bootstrap, Gitea-Bundles, Secrets-Inventur
Q3	mealie oder nextcloud	DNS-Pfad und Cert-Expiry-Sicht
Q4	vaultwarden oder gitea	Externe Abhaengigkeiten, Hetzner, GitHub-Mirror

Bestaetigte Mini-Restores: Vaultwarden, Gitea und Paperless am 2026-05-07; Immich am 2026-05-27; Paperless erneut am 2026-05-31.

Konkreter Kalender

• Jeden Montag, 06:30:
  • check-restore-freshness.sh
• Jeden 1. Samstag im Monat, 07:00:
  • vaultwarden
• Jeden 3. Samstag im Monat, 07:00:
  • gitea
• Jeden 2. Samstag in ungeraden Monaten, 08:00:
  • paperless
• Jeden 1. des Monats, 09:00:
  • monthly-random-restore.sh
• Quartalsweise am 1. Werktag des Quartals:
  • DR-/Restore-Sanity-Check
• Quartalsweise am 2. Sonntag im zweiten Quartalsmonat, 08:30:
  • immich

Unraid User Scripts Cron

Script	Cron	Bedeutung
restore-freshness-weekly	30 6 * * 1	jeden Montag 06:30
restore-vaultwarden-monthly	0 7 1-7 * 6	erster Samstag im Monat 07:00
restore-gitea-monthly	15 7 15-21 * 6	dritter Samstag im Monat 07:15
restore-paperless-bimonthly	0 8 8-14 1,3,5,7,9,11 *	zweiter Samstag in ungeraden Monaten 08:00
restore-immich-quarterly	30 8 8-14 2,5,8,11 0	zweiter Sonntag in Feb/Mai/Aug/Nov 08:30
monthly-random-restore	0 9 1 * *	erster Kalendertag im Monat 09:00

Betriebsmodus

• V1:
  • Bash-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

Quartals-Sanity

Kurz pruefen:

• docs/DISASTER_RECOVERY.md Phase 1-5 passt noch zum Repo.
• docs/RESTORE_MATRIX.md Tier-Klassifizierung und letzte Restore-Erfolge stimmen.
• docs/SECRETS_MAP.md enthaelt die noetigen Secret-Pfade ohne Werte.
• Gitea-Bundles sind frisch und klonbar.
• GitHub-Mirror ist erreichbar und aktuell.
• ntfy-Testnachricht an homelab-info kommt an.
• Offline-Kopie der Borg-Passphrase ist auffindbar.
• Capacity-Stand passt zu docs/CAPACITY_AND_LIFECYCLE.md.

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.