Kubernetes Backup mit Velero: Strategie, Praxis und Disaster Recovery

TL;DR

• Velero sichert sowohl Kubernetes-Ressourcen (Deployments, Services, ConfigMaps) als auch Persistent Volumes -- beides ist notwendig.
• Backups ohne regelmaessige Restore-Tests sind wertlos. Testen Sie mindestens monatlich in einem separaten Namespace.
• Fuer Datenbanken auf Kubernetes reicht Velero allein nicht: Nutzen Sie datenbankspezifische Tools (pg_dump, mysqldump) als Pre-Hooks.
• Backup-Schedules sollten sich nach RPO richten: kritische Workloads stuendlich, alles andere taeglich.
• S3-kompatibles Storage als Backup-Ziel verwenden -- das funktioniert mit AWS, GCP, MinIO und den meisten EU-Cloud-Anbietern.

Warum Kubernetes-Backups anders funktionieren

Ein Kubernetes-Cluster besteht aus zwei Kategorien von Daten, die Sie sichern muessen: dem Cluster-State (alle API-Objekte wie Deployments, Services, Secrets, CRDs) und den Persistent Volumes (die eigentlichen Anwendungsdaten). Viele Teams sichern nur eins von beidem -- und merken es erst beim Restore.

Klassische VM-Backups greifen bei Kubernetes nicht. Ein Snapshot der Worker-Nodes nuetzt nichts, wenn der etcd-State verloren geht. Und ein etcd-Backup allein hilft nicht, wenn die Persistent Volumes auf separatem Storage liegen.

Velero loest dieses Problem, indem es beides kombiniert: Es spricht die Kubernetes API an, um Ressourcen zu exportieren, und nutzt Storage-Provider-Plugins oder Kopia (den Nachfolger von Restic), um Volume-Daten zu sichern.

Velero installieren und konfigurieren

Die Installation erfolgt ueber die Velero CLI oder Helm. Hier der Weg ueber die CLI mit einem S3-kompatiblen Backend:

# Velero CLI installieren
curl -fsSL https://github.com/vmware-tanzu/velero/releases/download/v1.15.0/velero-v1.15.0-linux-amd64.tar.gz | tar xz
sudo mv velero-v1.15.0-linux-amd64/velero /usr/local/bin/

# Credentials-Datei erstellen
cat <<EOF > /tmp/credentials-velero
[default]
aws_access_key_id=IHRE_ACCESS_KEY
aws_secret_access_key=IHRE_SECRET_KEY
EOF

# Velero installieren (Beispiel mit S3-kompatiblem Storage)
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.11.0 \
  --bucket kubernetes-backups \
  --secret-file /tmp/credentials-velero \
  --backup-location-config region=eu-central-1,s3ForcePathStyle=true,s3Url=https://s3.eu-central-1.amazonaws.com \
  --use-node-agent \
  --default-volumes-to-fs-backup

# Installation pruefen
kubectl get pods -n velero
velero version

Die Option --use-node-agent aktiviert den Kopia-basierten File-System-Backup-Mechanismus (den Nachfolger von Restic). Das ist wichtig fuer Volumes, die keinen nativen Snapshot-Support haben.

Backup-Strategien definieren

Nicht jeder Workload braucht die gleiche Backup-Frequenz. Definieren Sie Ihre Strategie nach RPO (Recovery Point Objective):

Velero unterstuetzt Schedules direkt:

# Stuendliches Backup fuer den Namespace "production"
velero schedule create production-hourly \
  --schedule="0 * * * *" \
  --include-namespaces production \
  --ttl 168h

# Taegliches Backup fuer Cluster-Ressourcen
velero schedule create cluster-daily \
  --schedule="0 2 * * *" \
  --include-cluster-resources=true \
  --ttl 720h

# Backup-Status pruefen
velero schedule get
velero backup get

Datenbank-Backups: Pre- und Post-Hooks

Velero kann Volumes per Filesystem-Backup sichern, aber fuer Datenbanken ist das nicht ausreichend. Ein Volume-Snapshot einer laufenden PostgreSQL-Instanz kann inkonsistente Daten enthalten. Nutzen Sie stattdessen Pre-Backup-Hooks, um einen konsistenten Dump zu erstellen:

apiVersion: v1
kind: Pod
metadata:
  name: postgres-0
  annotations:
    pre.hook.backup.velero.io/command: '["/bin/bash", "-c", "PGPASSWORD=$POSTGRES_PASSWORD pg_dump -U postgres -d myapp > /backup/dump.sql"]'
    pre.hook.backup.velero.io/timeout: "120s"
    post.hook.backup.velero.io/command: '["/bin/bash", "-c", "rm -f /backup/dump.sql"]'

Fuer MySQL/MariaDB analog:

annotations:
  pre.hook.backup.velero.io/command: '["/bin/bash", "-c", "mysqldump -u root -p$MYSQL_ROOT_PASSWORD --all-databases > /backup/dump.sql"]'
  pre.hook.backup.velero.io/timeout: "300s"

Restore testen -- der wichtigste Schritt

Ein Backup, das nicht getestet wurde, ist kein Backup. Richten Sie einen regelmaessigen Restore-Test ein:

# Restore in einen separaten Namespace
velero restore create test-restore \
  --from-backup production-hourly-20260210120000 \
  --namespace-mappings production:restore-test

# Restore-Status pruefen
velero restore describe test-restore --details

# Anwendung im Test-Namespace validieren
kubectl get pods -n restore-test
kubectl logs -n restore-test <pod-name>

# Test-Namespace nach Validierung aufraeumen
kubectl delete namespace restore-test

Automatisieren Sie diesen Test als CronJob oder CI/CD-Pipeline-Step. Wenn der Restore eines kritischen Service laenger als Ihr RTO dauert, muessen Sie Ihre Strategie anpassen.

Disaster Recovery: RTO und RPO einhalten

Fuer echtes Disaster Recovery brauchen Sie ein Backup-Ziel, das unabhaengig vom Cluster ist. Wenn Ihr Cluster in einem Rechenzentrum laeuft und das gesamte Rechenzentrum ausfaellt, muessen die Backups woanders liegen.

Empfohlene Architektur:

• Primaeres Backup-Ziel: S3-Bucket in der gleichen Region (schnelle Backups und Restores)
• Sekundaeres Backup-Ziel: S3-Bucket in einer anderen Region oder bei einem anderen Anbieter (Geo-Redundanz)
• Velero unterstuetzt mehrere BackupStorageLocations -- konfigurieren Sie mindestens zwei

Verschluesselung und Zugriffskontrolle

Backups enthalten Secrets, ConfigMaps und potenziell sensible Anwendungsdaten. Schuetzen Sie diese:

• Server-Side Encryption (SSE): Aktivieren Sie SSE-S3 oder SSE-KMS auf dem S3-Bucket.
• Zugriff einschraenken: Der Service-Account fuer Velero braucht nur Zugriff auf den Backup-Bucket, nicht auf andere Ressourcen.
• Backup-Bucket nicht oeffentlich machen: Klingt offensichtlich, passiert aber regelmaessig.
• Immutable Backups: Aktivieren Sie Object Lock auf dem S3-Bucket, um Backups vor versehentlichem oder boesartigem Loeschen zu schuetzen.

Velero mit Helm installieren (Alternative)

Fuer Teams, die ihre gesamte Cluster-Konfiguration als Helm Charts verwalten, ist die Helm-Installation oft die bessere Wahl:

# Velero Helm Repo hinzufuegen
helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
helm repo update

# Values-Datei erstellen
cat <<EOF > velero-values.yaml
configuration:
  backupStorageLocation:
    - name: default
      provider: aws
      bucket: kubernetes-backups
      config:
        region: eu-central-1
        s3ForcePathStyle: true
  volumeSnapshotLocation:
    - name: default
      provider: aws
      config:
        region: eu-central-1
  defaultVolumesToFsBackup: true
deployNodeAgent: true
credentials:
  useSecret: true
  secretContents:
    cloud: |
      [default]
      aws_access_key_id=IHRE_ACCESS_KEY
      aws_secret_access_key=IHRE_SECRET_KEY
schedules:
  production-hourly:
    disabled: false
    schedule: "0 * * * *"
    template:
      includedNamespaces:
        - production
      ttl: "168h"
  cluster-daily:
    disabled: false
    schedule: "0 2 * * *"
    template:
      includeClusterResources: true
      ttl: "720h"
EOF

# Velero installieren
helm install velero vmware-tanzu/velero \
  --namespace velero \
  --create-namespace \
  -f velero-values.yaml

Der Vorteil der Helm-Installation: Schedules, Credentials und Konfiguration leben in einer einzigen Datei, die Sie versionieren koennen.

Backup-Monitoring mit Prometheus

Ein Backup, das leise fehlschlaegt, ist schlimmer als kein Backup -- weil Sie sich in falscher Sicherheit wiegen. Velero exportiert Prometheus-Metriken, die Sie unbedingt nutzen sollten:

# PrometheusRule fuer Velero-Alerting
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: velero-alerts
  namespace: velero
spec:
  groups:
    - name: velero
      rules:
        - alert: VeleroBackupFailed
          expr: increase(velero_backup_failure_total[1h]) > 0
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Velero Backup fehlgeschlagen"
            description: "In der letzten Stunde ist mindestens ein Velero Backup fehlgeschlagen."
        - alert: VeleroBackupNotRunning
          expr: time() - velero_backup_last_successful_timestamp{schedule!=""} > 7200
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "Velero Backup ueberfaellig"
            description: "Das letzte erfolgreiche Backup fuer Schedule {{ $labels.schedule }} ist aelter als 2 Stunden."

Integrieren Sie diese Alerts in Ihren bestehenden Alertmanager. Ein Backup-Fehler sollte die gleiche Prioritaet haben wie ein Service-Ausfall.

Velero Backup vs. etcd Backup

Eine haeufige Frage: Brauche ich zusaetzlich zu Velero noch ein etcd-Backup? Die Antwort: Ja, fuer Self-Managed Cluster. Nein, fuer Managed Kubernetes (EKS, AKS, GKE).

Fuer Self-Managed Cluster (kubeadm, k3s, RKE2) sollten Sie beides haben: Velero fuer granulare, anwendungsbezogene Backups und ein etcd-Snapshot fuer die Cluster-Recovery im Worst Case.

# etcd Snapshot erstellen (nur Self-Managed Cluster)
ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

# Snapshot verifizieren
ETCDCTL_API=3 etcdctl snapshot status /backup/etcd-snapshot.db --write-table

Haeufige Fehler und wie Sie sie vermeiden

1. Nur Ressourcen sichern, Volumes vergessen: Ohne --default-volumes-to-fs-backup sichert Velero nur die Kubernetes-Objekte, nicht die Volume-Daten.

2. Backup-Schedule ohne Monitoring: Wenn ein Backup fehlschlaegt, muessen Sie das sofort wissen. Integrieren Sie Velero-Metriken in Prometheus:

# Velero exportiert Metriken auf Port 8085
kubectl port-forward -n velero deployment/velero 8085:8085
curl http://localhost:8085/metrics | grep velero_backup

3. Restore nie getestet: Der haeufigste und teuerste Fehler. Planen Sie monatliche Restore-Tests fest ein.

4. Backup-Retention zu kurz: Wenn Sie ein korruptes Backup erst nach einer Woche bemerken und nur 7 Tage aufbewahren, haben Sie kein gutes Backup mehr.

Zusammenfassung

Ein solides Kubernetes-Backup-Konzept besteht aus drei Saeulen: regelmaessige automatisierte Backups mit Velero, datenbankspezifische Hooks fuer konsistente Datenbank-Sicherungen, und regelmaessige Restore-Tests. Alles andere ist optional.

Weiterführende Artikel

• Kubernetes Storage: Performance und Konfiguration
• Kubernetes Security Hardening Checkliste
• Kubernetes Secrets Management mit Vault
• Kubernetes Monitoring: Kosten senken mit Open Source

Wenn Sie Hilfe bei der Planung Ihrer Backup- und Disaster-Recovery-Strategie brauchen oder eine bestehende Velero-Installation auditieren lassen moechten, melden Sie sich bei uns -- zum Kontaktformular.