# 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
- pruefen:
  - Restore-Lab-Struktur
  - Reports
  - Skripte und Pfade
  - Doku noch passend

Spaeter:

- `immich` als eigener Sprint

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