# Backup-/Restore-Artefaktklassen — kube-bot Bewertung

Stand: 2026-06-21

## Ziel

Nicht jedes Cluster-Artefakt sollte gleich gesichert werden. Der Homarr-Pilot hat Transport, Verschluesselung, Checksums und Manifest-Dry-Run bewiesen, war aber bewusst kein vollstaendiger App-Restore.

## Klassen

### Klasse A — Metadaten/Manifeste

Geeignet fuer:
- Kubernetes Manifeste
- Status-/Inventar-Snapshots
- GitOps-Exporte
- Secret-Referenzen ohne Werte
- PV/PVC/Longhorn-Metadaten

Empfohlene Methode:
- tar.gz
- clientseitig mit `age` verschluesseln, wenn sensible Metadaten enthalten sind
- `.sha256`
- Ablage ueber `dmz-backup` nach DiskStation

Restore-Wert:
- gut fuer Analyse, Vergleich, Rebuild-Planung und Server-Dry-Run
- nicht ausreichend fuer App-Datenrestore

Homarr-Pilot 2026-06-20/21 gehoert in diese Klasse.

### Klasse B — App-Dateien / PVC-Payload

Geeignet fuer:
- Upload-Verzeichnisse
- App-Konfiguration auf PVC
- kleinere Dateibestaende
- exportierbare App-Daten

Empfohlene Methode:
- bei kleinen Daten: tar.zst/tar.gz + `age`
- bei groesseren oder inkrementellen Daten: `rsync` in ein staging directory, danach optional Paket/Checksum/Encryption
- bei regelmaessigen Backups: Restic evaluieren, weil es verschluesselt, inkrementell und pruefbar ist

Restore-Wert:
- echter App-Restore moeglich, wenn Manifeste und PVC-Zielpfade sauber vorbereitet sind
- Restore immer zuerst in isoliertem Namespace/PVC testen

### Klasse C — Datenbanken

Geeignet fuer:
- MariaDB/MySQL/Postgres Dumps
- App-spezifische Export-Formate

Empfohlene Methode:
- konsistenter Dump aus App-/DB-Kontext
- komprimieren und verschluesseln
- `.sha256` + Metadaten mit DB-Version, Namespace, App, Dump-Zeit

Restore-Wert:
- deutlich besser als rohe PVC-Snapshots fuer DB-Apps
- Restore-Probe muss Import in isolierte DB/App-Instanz enthalten

### Klasse D — Longhorn Volume Backups

Geeignet fuer:
- groessere PVCs
- blockbasierte Volume-Wiederherstellung
- Apps, bei denen Dateiexport nicht praktikabel ist

Empfohlene Methode:
- Longhorn BackupTarget/Backup-Mechanik verwenden
- Backup-Referenzen und Volumen-Metadaten separat dokumentieren
- nicht versuchen, Longhorn Live-CR-Dumps direkt als Restore-Manifeste zu applyen

Restore-Wert:
- echter PVC-/Volume-Restore moeglich
- muss mit neuem PVC/isoliertem Namespace geprobt werden

### Klasse E — S3/Object Store

Geeignet fuer:
- groessere zentrale Backup-Repositories
- Restic/Kopia Repositories
- spaetere standardisierte Retention/Pruning-Policies

Empfohlene Methode:
- erst evaluieren, wenn mehrere Apps echte Payload-Backups brauchen
- Secrets/Passphrases in Infisical, nicht im Cluster-Repo oder auf `dmz-backup`

Restore-Wert:
- gut fuer skalierte Automatisierung
- mehr Betriebs-/Policy-Aufwand als einfacher SSH-Dateitransport

## Automatisierungsideen

Kurzfristig:
- DiskStation-Skript fuer Homarr/K3s-DMZ:
  - Quelle auf `dmz-backup` pruefen
  - `.sha256` pruefen
  - nach DiskStation kopieren
  - DiskStation-SHA pruefen
  - konkrete Quelle auf `dmz-backup` nach freigegebener Regel loeschen
  - Status/Log schreiben
- kube-bot CronJob/Script nur fuer read-only Export + clientseitige Verschluesselung + Push nach `dmz-backup`.

Mittelfristig:
- pro Artefaktklasse eigene Backup-Profile:
  - `metadata`
  - `db-dump`
  - `files`
  - `longhorn-backup`
- Restore-Test-Cron nur fuer nicht-produktive Validierung:
  - Checksums
  - Decrypt
  - Archiv listen
  - Kubernetes Server-Dry-Run

Noch nicht automatisieren:
- produktive Restores
- PVC-Ueberschreiben
- Longhorn Restore in produktive Volumes
- Secrets im Klartext

## Offene Entscheidung

Fuer Homarr als naechsten echten Restore-Test entscheiden:

1. PVC-Dateien exportieren und als `files`-Artefakt sichern.
2. Longhorn Backup fuer die Homarr-PVCs erstellen und Restore in isoliertem Namespace testen.
3. Falls Homarr eine sinnvollere App-/DB-Exportmethode hat, diese bevorzugen.

Kube-bot-Empfehlung: Fuer den naechsten Schritt Longhorn-Backup-Referenz oder PVC-Payload verwenden; Metadata-Pilot nicht weiter als vollstaendiges Restore-Artefakt behandeln.