79 lines
1.9 KiB
Markdown
79 lines
1.9 KiB
Markdown
# 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
|