# Longhorn Restore-Test — kube-bot Review

Stand: 2026-06-09 12:16 UTC

## Ziel
Nachweisen, dass aus dem von Synology gepullten Longhorn-Backupbestand ein nutzbares Test-Volume wiederhergestellt werden kann, ohne produktive PVCs oder Workloads zu verändern.

## Aktuell validiert
- Longhorn BackupTarget: `nfs://192.168.20.40:/srv/longhorn-backup-staging`, `available=true`
- Synology Pull: read-only NFS + `rsync -a --stats --exclude lost+found/`, kein `--delete`
- Letzter Sync: `STATUS=ok`, Source/Target exakt gleich
- Nodes Ready, Longhorn Manager Running
- Staging-Export für Synology: `192.168.13.10(ro,insecure,root_squash)`

## Restore-Test-Prinzip
1. Nicht gegen produktive Namespaces/PVCs testen.
2. Isolierten Namespace verwenden, z. B. `restore-test-longhorn`.
3. Test-PVC aus Longhorn-Backup wiederherstellen.
4. Nur lesenden/harmlosen Test-Pod starten, z. B. BusyBox/Alpine, um Mount und Dateien zu prüfen.
5. Ergebnis dokumentieren: PVC bound, Pod running/completed, erwartete Daten sichtbar.
6. Danach Testressourcen entfernen — Löschung ebenfalls nur mit explizitem OK, weil Cluster-Änderung.

## Wichtige offene Entscheidung vor Ausführung
- Welcher Backupstand wird getestet?
  - Kandidat: Testbackup `backup-e4f3dcd9692e4f50` von Volume `pvc-f6714be0-39b1-47e6-baa2-2e1ae801d907` (`hf-matomo/matomo-pvc`).
- Soll der Restore-Test nur Longhorn-Volume-Mount prüfen oder auch applikationsspezifische Konsistenz?
  - Empfehlung erster Lauf: nur Volume-Restore/Mount/Dateisichtbarkeit, keine App-Integration.

## Nicht ohne explizites OK
- Restore ausführen
- Namespace/PVC/Pod anlegen
- produktive PVCs verändern/überschreiben
- Longhorn Settings, Replica Counts, StorageClasses ändern
- Retention-Pruning oder `--delete`

## Empfehlung
Nächster sinnvoller Schritt ist Review des DiskStation-Restore-Testplans gegen diese Guardrails. Danach Mislav gezielt um OK für einen isolierten Restore-Test bitten, wenn er ihn ausführen möchte.