Micha/homelab-infra
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
aecf3b2807d0f6b082cd38e078055fbfc12ba1ae
homelab-infra/ops/restore-tests/schedule.md
T
Micha c4fd4154db Document quarterly restore drill routine 
New docs/RESTORE_DRILL_ROUTINE.md introduces a three-stage model:
weekly freshness check, monthly/bimonthly mini-restores, quarterly
DR sanity check. Tracks confirmed mini-restores (Vaultwarden, Gitea,
Paperless 2026-05-07; Immich 2026-05-27) and rotates services by
quarter Q1-Q4. Includes ten-point DR sanity check and abort rules
that point at the drift runbook. No host schedule is created; the
existing ops/restore-tests/schedule.md now references this routine
as the source for quarterly assignment.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 20:15:43 +02:00

2.9 KiB
Raw Blame History

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 gemaess docs/RESTORE_DRILL_ROUTINE.md
  • 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

Die Quartals-Belegung (welcher Dienst, welcher Sanity-Fokus) steht in docs/RESTORE_DRILL_ROUTINE.md Tabelle "Quartals-Kadenz".

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

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.

Reference in New Issue View Git Blame Copy Permalink