Backup und Restore

Die Plattform bietet ein automatisches Backup-System als Kubernetes CronJob. Standardmäßig ist es deaktiviert und muss explizit aktiviert werden.

Backup aktivieren¶

Helm Value: backup.enabled: true (über Customer Portal → Updates)
Oder bei Installation: backup.enabled=true in den Helm Values

Automatisches Backup¶

Zeitplan: Täglich um 02:00 Uhr
Aufbewahrung: 7 Backups (ältere werden automatisch gelöscht)
Speicher: 20 Gi PVC unter /backups/

Was wird gesichert?¶

Daten	Methode	Ausgabe
PostgreSQL (alle DBs)	`pg_dumpall --clean --if-exists`	`postgres-all.sql`
MongoDB	`mongodump --gzip`	`mongodb/`-Verzeichnis
Qdrant (Vektordaten)	REST Snapshot API	`qdrant-{collection}-{snapshot}.snapshot`

Hochgeladene Dateien sind nicht Teil des Backups

Der Upload-Zwischenspeicher der RAG API hält eine Datei nur zwischen dem Hochladen und ihrer Verarbeitung — danach wird sie gelöscht. Gesichert werden muss er deshalb nicht: Die verwertbaren Inhalte liegen nach der Verarbeitung in Qdrant und sind dort im Backup enthalten.

Die Originaldateien selbst bewahrt die Plattform nicht dauerhaft auf. Wer sie behalten möchte, hält sie in der Quelle vor, aus der sie stammen.

Konfigurationsdaten nicht im Backup

Konfigurationsdaten (Secrets, ConfigMaps) werden NICHT durch das Backup gesichert. Diese sind im Helm Chart und den Values definiert.

Backup manuell auslösen¶

# CronJob manuell triggern
kubectl create job --from=cronjob/inovetra-backup manual-backup-$(date +%Y%m%d) -n inovetra-platform

# Status prüfen
kubectl get jobs -n inovetra-platform | grep backup

# Logs des Backup-Jobs
kubectl logs job/manual-backup-$(date +%Y%m%d) -n inovetra-platform

Restore-Prozedur¶

Datenverlust möglich

Ein Restore überschreibt die aktuellen Daten. Vorher Backup des aktuellen Stands erstellen!

PostgreSQL Restore¶

# Temporären Pod mit Backup-PVC starten, um Backup-Dateien zu identifizieren
kubectl run backup-inspect --rm -it --image=postgres:18-alpine \
  --overrides='{"spec":{"containers":[{"name":"backup-inspect","image":"postgres:18-alpine","command":["sh"],"volumeMounts":[{"name":"backup","mountPath":"/backups"}]}],"volumes":[{"name":"backup","persistentVolumeClaim":{"claimName":"inovetra-backup"}}]}}' \
  -n inovetra-platform -- ls -la /backups/

# Restore über temporären Pod ausführen
kubectl run pg-restore --rm -it --image=postgres:18-alpine \
  --overrides='{"spec":{"containers":[{"name":"pg-restore","image":"postgres:18-alpine","command":["sh"],"volumeMounts":[{"name":"backup","mountPath":"/backups"}]}],"volumes":[{"name":"backup","persistentVolumeClaim":{"claimName":"inovetra-backup"}}]}}' \
  -n inovetra-platform -- \
  psql -h inovetra-postgres -U inovetra-postgres -f /backups/<datum>/postgres-all.sql

MongoDB Restore¶

# Temporären Pod mit Backup-PVC starten und Restore durchführen
kubectl run mongo-restore --rm -it --image=mongo:7.0 \
  --overrides='{"spec":{"containers":[{"name":"mongo-restore","image":"mongo:7.0","command":["sh"],"volumeMounts":[{"name":"backup","mountPath":"/backups"}]}],"volumes":[{"name":"backup","persistentVolumeClaim":{"claimName":"inovetra-backup"}}]}}' \
  -n inovetra-platform -- \
  mongorestore --host inovetra-mongodb --gzip --drop /backups/<datum>/mongodb/

Qdrant Restore¶

# Port-Forwarding zu Qdrant
kubectl port-forward svc/inovetra-vectordb 6333:6333 -n inovetra-platform

# Snapshot-Datei aus Backup-PVC kopieren
kubectl cp inovetra-platform/<backup-pod>:/backups/<datum>/qdrant-documents-<snapshot>.snapshot ./snapshot.snapshot

# Snapshot hochladen und wiederherstellen (via REST API)
curl -X POST "http://localhost:6333/collections/documents/snapshots/upload" \
  -H "Content-Type: multipart/form-data" \
  -F "snapshot=@./snapshot.snapshot"

Restore testen¶

Empfehlung: Quartalsweise einen Restore-Test in einer Testumgebung durchführen.

Prüfpunkte nach Restore:

Alle Pods starten erfolgreich
Login im Customer Portal funktioniert
Chat-Verlauf in LibreChat vorhanden
RAG-Dokumente abrufbar
Connector-Konfigurationen intakt