Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// installation

Backup & Wiederherstellung

Gilt für

Produkt: Server · Zielgruppe: Platform Operator

Was gesichert werden muss (Datenbanken, Medien, Konfiguration, Secrets), was neu erzeugt werden kann (Modellartefakte, Caches), wie oft, wohin – und wie Sie wiederherstellen. Die eine Regel, die alles andere überragt: Vor jedem Upgrade die AISRV-Datenbank sichern. Datenbankmigrationen sind vorwärts gerichtet; ohne Backup gibt es keinen Weg zurück.

Was gesichert wird – und was nicht

Sichern	Ort	Warum
`aisrv-db`	CloudNativePG-Cluster	Benutzer, Organisationen, Apps, Einstellungen, Audit-Log, Konnektor-Zugangsdaten – der Kern
`idp-db`	CloudNativePG-Cluster	Identitäten, Realms, Clients – ohne sie kein Login
`storesrv-db`	CloudNativePG-Cluster	Persistenz des Store-Servers
`ragsrv-db`	CloudNativePG-Cluster (pgvector)	Dokumentabschnitte und Embeddings; alternativ Wissensbasen neu aufnehmen (dauert)
Medien-Volume	PVC unter `AISRV_MEDIA_ROOT`	Hochgeladene Dateien
Kubernetes-Secrets	`aisrv-database`, `storesrv-database`, `ragsrv-database`, `idp-database`, `keycloak-admin-secret`, `basebox-admin-secret`, TLS-Secret, Inferenz-/Registry-Schlüssel	Ohne sie ist eine wiederhergestellte Datenbank nicht nutzbar
Values-Dateien	Ihr Git (ohne Secrets)	Reproduzierbare Installation
Manifest	Versionen, Image-Digests, GPU-Layout	Für Wiederaufbau und Support

Nicht sichern (neu erzeugbar)	Anmerkung
Modellgewichte (`inference-models`, `ragsrv-support-models`)	Neu ladbar – im abgeschotteten Betrieb den Mirror vorhalten
Caches (Numba, Triton, `/tmp/ragsrv`)	Werden neu aufgebaut
Container-Images	Aus der Registry oder dem Mirror

Methode 1: CloudNativePG-Backups (empfohlen)

Automatisierte Backups je Cluster nach S3-kompatiblem Speicher, in den Values:

aisrv:
  aisrv-db:
    cluster:
      backup:
        barmanObjectStore:
          destinationPath: s3://backups/aisrv
          s3Credentials:
            accessKeyId:
              name: backup-s3-creds
              key: ACCESS_KEY_ID
            secretAccessKey:
              name: backup-s3-creds
              key: SECRET_ACCESS_KEY
        retentionPolicy: "30d"

Analog für idp.idp-db, storesrv.storesrv-db, ragsrv.ragsrv-db. CloudNativePG erlaubt geplante Backups (ScheduledBackup), kontinuierliche WAL-Archivierung und Point-in-Time-Recovery; das Verfahren steht in der CloudNativePG-Dokumentation. Das S3-Ziel kann ein interner Objektspeicher (z. B. MinIO) sein – im abgeschotteten Betrieb der einzige Weg.

Methode 2: Dumps

Für Einzelsicherungen und vor Upgrades:

kubectl exec -n basebox aisrv-db-1    -- pg_dump -U aisrv    aisrv    > aisrv-backup.sql
kubectl exec -n basebox idp-db-1      -- pg_dump -U idp      idp      > idp-backup.sql
kubectl exec -n basebox storesrv-db-1 -- pg_dump -U storesrv storesrv > storesrv-backup.sql
kubectl exec -n basebox ragsrv-db-1   -- pg_dump -U ragsrv   ragsrv   > ragsrv-backup.sql

Dumps enthalten personenbezogene Daten und (nur schreibend gespeicherte) Zugangsdaten: verschlüsselt ablegen, Zugriff begrenzen.

Medien und Secrets

# Medien-Volume: mit Ihrem Volume-Snapshot-Werkzeug oder Kopie aus dem Pod
kubectl -n basebox exec deploy/aisrv -- tar czf - -C "$AISRV_MEDIA_ROOT" . > media-backup.tgz

# Secrets exportieren (verschlüsselt ablegen!)
kubectl -n basebox get secret -o yaml > basebox-secrets.yaml

Vor jedem Upgrade

Dump der aisrv-db (und der anderen Datenbanken) oder ein frisches CloudNativePG-Backup.
Optional zusätzlich AISRV_DB_MIGRATE_BACKUP: "true" mit AISRV_DB_MIGRATE_BACKUP_DIR auf einem persistenten Volume – AISRV sichert dann vor Migrationen selbst.
Values-Dateien und helm list -n basebox festhalten.

Konkret bei basebox 1.8.6: Die AISRV-Migration V32 ist ohne das vorherige Backup nicht rückgängig zu machen. Ablauf: Updates.

Häufigkeit und Aufbewahrung (Vorschlag)

Was	Häufigkeit	Aufbewahrung
Datenbanken (CNPG)	Täglich voll, WAL kontinuierlich	30 Tage; länger nach Ihren Richtlinien
Medien-Volume	Täglich (Snapshot)	30 Tage
Secrets, Values, Manifest	Bei jeder Änderung	Versioniert
Vor Upgrades	Jeweils	Bis das Upgrade abgenommen ist, mindestens

Stimmen Sie Aufbewahrung mit dem Datenschutz ab: Backups enthalten Audit-Log und – je nach Detailtiefe – Gesprächsinhalte; Löschfristen gelten auch für Backups (Aufbewahrung, Löschung).

Wiederherstellung

Einzelne Datenbank aus Dump:

kubectl -n basebox scale deploy/aisrv --replicas=0
kubectl exec -i -n basebox aisrv-db-1 -- psql -U aisrv aisrv < aisrv-backup.sql
kubectl -n basebox scale deploy/aisrv --replicas=1

Aus CloudNativePG-Backup: neuen Cluster mit bootstrap.recovery aus dem Objektspeicher anlegen (optional Point-in-Time), dann die Dienste darauf zeigen lassen – nach der CloudNativePG-Dokumentation.

Gesamter Server (Neuaufbau):

Cluster nach dem Bare-Metal-Pfad bis einschließlich Kubernetes aufbauen.
Secrets einspielen (kubectl apply -f basebox-secrets.yaml), bevor basebox installiert wird.
basebox mit denselben Values-Dateien und derselben Chart-Version installieren (helm upgrade --install … --version <alt>).
Datenbanken wiederherstellen (Dump oder CNPG-Recovery), Medien-Volume zurückspielen.
Modelle laden lassen (oder aus dem Mirror), Abnahmeprüfung nach Installation prüfen.

Daten beim Deinstallieren erhalten: helm uninstall basebox -n basebox lässt die PVCs stehen; eine Neuinstallation mit denselben Values nutzt sie weiter. PVCs nur löschen, wenn Sie den Datenverlust wollen.

Wiederherstellung üben

Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung. Monatlich (oder vor jedem Major-Upgrade) in eine Testumgebung oder einen Test-Namespace wiederherstellen, Login und eine RAG-Antwort prüfen, Dauer festhalten. Das ist zugleich der Nachweis für Audits.

Hosting oder Betrieb durch basebox

Beim Betrieb durch basebox gehören Backup-Ziel, Häufigkeit, Aufbewahrung und Wiederherstellungstests in den Vertrag – siehe Betrieb durch basebox. Beim Hosting ohne Betriebsauftrag bleiben Backups Ihre Aufgabe.

Nächster Schritt: Updates