# 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