homelab-infra/ops/restore-tests/automation-plan.md

Restore Automation Plan

Ziel

Die bereits validierten Restore-Tests fuer vaultwarden, gitea und paperless sollen regelmaessig mit wenig Handarbeit laufen.

Prinzip

• Ausfuehrung bleibt hostseitig
• Logik bleibt im Repo
• Reports bleiben unter /mnt/user/backups/restore-reports
• Restore-Arbeitsdaten bleiben unter /mnt/user/backups/restore-lab
• Hermes ist Reporter, nicht Operator

V1

Woechentlicher Frische-Check

• Script: check-restore-freshness.sh
• Ziel:
  • Dump-Dateien vorhanden
  • Dump-Dateien nicht zu alt
  • letzte Restore-Reports vorhanden
• Wirkung:
  • schneller Fruehwarncheck ohne Containerstart

Monatliche / zweimonatliche Restore-Jobs

• Script-Dispatcher: run-restore-checks.sh
• Modi:
  • freshness
  • vaultwarden
  • gitea
  • paperless
• diese Bash-Jobs sind jetzt hostseitig praktisch verifiziert
• die *.ps1-Dateien bleiben als Plan-/Hilfsvariante fuer die Windows-Arbeitskopie erhalten

V2

• ntfy Erfolg/Fehler
• optional Hermes-Zusammenfassung ueber vorhandene Reports
• spaeter Job-Metadaten, Rotation und Sammel-Reports weiter ausbauen

ntfy-Muster

• Script: run-restore-job-with-ntfy.sh
• Hilfsskript: send-ntfy.sh
• nur kurze Erfolg/Fehler-Meldung
• eigentlicher Detailnachweis bleibt die Markdown-Reportdatei

Host-Integration

Empfohlen:

• Unraid User Scripts
• je ein geplanter Job pro Laufklasse
• Ausfuehrung auf dem Unraid-Host, nicht im Windows-Clone

Beispiel:

1. restore-freshness-weekly
2. restore-vaultwarden-monthly
3. restore-gitea-monthly
4. restore-paperless-bimonthly

Erfolgskriterium

Ein automatisierter Lauf ist nur dann erfolgreich, wenn:

• Script sauber endet
• Report geschrieben wird
• bei echten Restore-Laeufen der definierte Smoke-Test erfolgreich war

Nicht automatisieren

• neue Restore-Typen ohne bewusste Freigabe
• invasive Produktiv-Restores
• Komodo-/Auth-/Secret-Umbauten im selben Job