# 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