71 lines
1.7 KiB
Markdown
71 lines
1.7 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.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
|