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.ps1
• 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.ps1
• Modi:
  • freshness
  • vaultwarden
  • gitea
  • paperless
• V1 ruft die existierenden dienstspezifischen Scripts zunaechst im WhatIf- oder Plan-Modus auf, bis die Vollautomatisierung je Dienst gezielt nachgezogen wird.

V2

• echte Vollautomatisierung pro Dienst
• ntfy Erfolg/Fehler
• optional Hermes-Zusammenfassung ueber vorhandene Reports

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