# 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 gemaess `docs/RESTORE_DRILL_ROUTINE.md`
- `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

Die Quartals-Belegung (welcher Dienst, welcher Sanity-Fokus) steht in `docs/RESTORE_DRILL_ROUTINE.md` Tabelle "Quartals-Kadenz".

## 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`

## 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.