136 lines
3.7 KiB
Markdown
136 lines
3.7 KiB
Markdown
# Restore Test Schedule
|
|
|
|
## Ziel
|
|
|
|
Regelmaessige Restore-Tests mit wenig Handarbeit und klaren Nachweisen.
|
|
|
|
## Intervalle
|
|
|
|
Woechentlich:
|
|
|
|
- Backup-/Dump-Frische pruefen
|
|
- keine echten Restore-Container starten
|
|
- pruefen:
|
|
- Dump-Dateien vorhanden
|
|
- Dump-Dateien nicht zu alt
|
|
- letzte Reports vorhanden
|
|
|
|
Monatlich:
|
|
|
|
- `vaultwarden` Mini-Restore
|
|
- `gitea` Mini-Restore, versetzt zum Vaultwarden-Lauf
|
|
|
|
Alle 2 Monate:
|
|
|
|
- `paperless` Mini-Restore
|
|
|
|
Quartalsweise:
|
|
|
|
- Restore-/DR-Sanity-Check
|
|
- `immich` Restore-Smoke-Test (DB + UI, ohne produktive Foto-Mounts; Erstlauf 2026-05-27 erfolgreich)
|
|
- pruefen:
|
|
- Restore-Lab-Struktur
|
|
- Reports
|
|
- Skripte und Pfade
|
|
- Doku noch passend
|
|
|
|
Quartals-Belegung:
|
|
|
|
| Quartal | Mini-Restore | Sanity-Fokus |
|
|
|---|---|---|
|
|
| Q1 | `paperless` | Tier-1-Reihenfolge, Posture-Check, Borg-Frische |
|
|
| Q2 | `immich` | Komodo-Bootstrap, Gitea-Bundles, Secrets-Inventur |
|
|
| Q3 | `mealie` oder `nextcloud` | DNS-Pfad und Cert-Expiry-Sicht |
|
|
| Q4 | `vaultwarden` oder `gitea` | Externe Abhaengigkeiten, Hetzner, GitHub-Mirror |
|
|
|
|
Bestaetigte Mini-Restores: Vaultwarden, Gitea und Paperless am 2026-05-07;
|
|
Immich am 2026-05-27; Paperless erneut am 2026-05-31.
|
|
|
|
## Konkreter Kalender
|
|
|
|
- Jeden Montag, 06:30:
|
|
- `check-restore-freshness.sh`
|
|
- Jeden 1. Samstag im Monat, 07:00:
|
|
- `vaultwarden`
|
|
- Jeden 3. Samstag im Monat, 07:00:
|
|
- `gitea`
|
|
- Jeden 2. Samstag in ungeraden Monaten, 08:00:
|
|
- `paperless`
|
|
- Jeden 1. des Monats, 09:00:
|
|
- `monthly-random-restore.sh`
|
|
- Quartalsweise am 1. Werktag des Quartals:
|
|
- DR-/Restore-Sanity-Check
|
|
- Quartalsweise am 2. Sonntag im zweiten Quartalsmonat, 08:30:
|
|
- `immich`
|
|
|
|
## Unraid User Scripts Cron
|
|
|
|
| Script | Cron | Bedeutung |
|
|
|---|---|---|
|
|
| `restore-freshness-weekly` | `30 6 * * 1` | jeden Montag 06:30 |
|
|
| `restore-vaultwarden-monthly` | `0 7 1-7 * 6` | erster Samstag im Monat 07:00 |
|
|
| `restore-gitea-monthly` | `15 7 15-21 * 6` | dritter Samstag im Monat 07:15 |
|
|
| `restore-paperless-bimonthly` | `0 8 8-14 1,3,5,7,9,11 *` | zweiter Samstag in ungeraden Monaten 08:00 |
|
|
| `restore-immich-quarterly` | `30 8 8-14 2,5,8,11 0` | zweiter Sonntag in Feb/Mai/Aug/Nov 08:30 |
|
|
| `monthly-random-restore` | `0 9 1 * *` | erster Kalendertag im Monat 09:00 |
|
|
|
|
## Betriebsmodus
|
|
|
|
- V1:
|
|
- Bash-Jobs laufen hostseitig manuell oder per User Script
|
|
- `ntfy` ist optional und folgt nach stabiler Basis
|
|
- Hermes wertet spaeter nur Reports aus
|
|
- V2:
|
|
- fester Host-Schedule
|
|
- `ntfy` bei Erfolg/Fehler
|
|
- Hermes erzeugt Zusammenfassungen und Overviews
|
|
|
|
## Automatisierung
|
|
|
|
Automatisch:
|
|
|
|
- Testpfad vorbereiten
|
|
- Restore in `restore-lab`
|
|
- Testcontainer `restoretest-*` starten
|
|
- Smoke-Test ausfuehren
|
|
- Markdown-Report schreiben
|
|
- `ntfy` Erfolg/Fehler senden
|
|
- alte Testartefakte bereinigen
|
|
|
|
Manuell:
|
|
|
|
- neue Testfaelle einfuehren
|
|
- riskante oder produktionsnahe Sondertests
|
|
- Aenderungen an Restore-Logik
|
|
- Freigabe fuer den ersten echten Restore je Dienst
|
|
|
|
## Ablage
|
|
|
|
- Quelle: `/mnt/user/backups/borg`
|
|
- Restore-Lab: `/mnt/user/backups/restore-lab`
|
|
- Reports: `/mnt/user/backups/restore-reports`
|
|
|
|
## Quartals-Sanity
|
|
|
|
Kurz pruefen:
|
|
|
|
- `docs/DISASTER_RECOVERY.md` Phase 1-5 passt noch zum Repo.
|
|
- `docs/RESTORE_MATRIX.md` Tier-Klassifizierung und letzte Restore-Erfolge stimmen.
|
|
- `docs/SECRETS_MAP.md` enthaelt die noetigen Secret-Pfade ohne Werte.
|
|
- Gitea-Bundles sind frisch und klonbar.
|
|
- GitHub-Mirror ist erreichbar und aktuell.
|
|
- ntfy-Testnachricht an `homelab-info` kommt an.
|
|
- Offline-Kopie der Borg-Passphrase ist auffindbar.
|
|
- Capacity-Stand passt zu `docs/CAPACITY_AND_LIFECYCLE.md`.
|
|
|
|
## Erfolgsregel
|
|
|
|
Ein Test gilt erst dann als erfolgreich, wenn:
|
|
|
|
- Restore abgeschlossen ist
|
|
- Testcontainer startet
|
|
- definierter Smoke-Test erfolgreich ist
|
|
- Report geschrieben wurde
|
|
|
|
Nur "Container laeuft" reicht nicht.
|