Velero Backup: Kubernetes-Cluster richtig sichern

TL;DR

Velero sichert Kubernetes-Ressourcen und optional Persistent Volumes in S3-kompatiblen Storage. Eine solide Backup-Strategie kombiniert tägliche Namespace-Backups mit wöchentlichen Cluster-Backups. Entscheidend ist nicht das Backup selbst, sondern der regelmäßig getestete Restore — nur ein geprüftes Backup ist ein echtes Backup.

Velero installieren

Velero besteht aus einem CLI-Tool und einem Server-Deployment im Cluster. Die Installation dauert unter fünf Minuten.

# Velero CLI installieren
# macOS:
brew install velero
# Linux:
curl -LO https://github.com/vmware-tanzu/velero/releases/download/v1.15.0/velero-v1.15.0-linux-amd64.tar.gz
tar -xzf velero-v1.15.0-linux-amd64.tar.gz
sudo mv velero-v1.15.0-linux-amd64/velero /usr/local/bin/

Für den Server-Teil brauchen Sie einen S3-kompatiblen Storage — AWS S3, MinIO, oder einen anderen Anbieter. Erstellen Sie die Credentials-Datei:

cat <<EOF > /tmp/velero-credentials
[default]
aws_access_key_id=IHRE_ACCESS_KEY_ID
aws_secret_access_key=IHR_SECRET_KEY
EOF

Dann Velero im Cluster deployen:

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.11.0 \
  --bucket kubernetes-backups \
  --secret-file /tmp/velero-credentials \
  --backup-storage-location-config \
    region=eu-central-1,s3ForcePathStyle=true \
  --use-volume-snapshots=false \
  --namespace velero

Für MinIO als On-Premises-Alternative ergänzen Sie s3Url=http://minio.minio.svc:9000 in der backup-storage-location-config. Eine detaillierte MinIO-Anleitung finden Sie unter Velero mit MinIO.

Prüfen Sie die Installation:

kubectl get pods -n velero
velero version

Backup-Strategie: Namespace vs. Cluster

Nicht jedes Backup muss den gesamten Cluster umfassen. Die Wahl zwischen Namespace-Level und Cluster-Level bestimmt Geschwindigkeit, Größe und Restore-Flexibilität.

Empfohlene Kombination: Tägliche Namespace-Backups für Applikations-Namespaces und wöchentliche Full-Cluster-Backups für die Gesamtsicherung inklusive RBAC, CRDs und ClusterRoles.

Schedules einrichten

Manuelle Backups vergisst man. Schedules sind Pflicht.

# daily-namespace-backup.yaml
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-production
  namespace: velero
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
      - production
      - staging
    ttl: 168h0m0s
    storageLocation: default
    snapshotVolumes: false
  useOwnerReferencesInBackup: false

kubectl apply -f daily-namespace-backup.yaml

# Oder per CLI — schneller für Ad-hoc-Setups:
velero schedule create weekly-full \
  --schedule="0 3 * * 0" \
  --ttl 720h

# Namespace-spezifisch mit Label-Selektor:
velero schedule create daily-critical \
  --schedule="0 1 * * *" \
  --include-namespaces production \
  --selector app.kubernetes.io/part-of=critical-stack \
  --ttl 336h

# Alle Schedules anzeigen:
velero schedule get

Die TTL (Time To Live) bestimmt, wie lange Backups aufbewahrt werden. 168h sind 7 Tage, 720h sind 30 Tage. Velero löscht abgelaufene Backups automatisch — auch aus dem S3-Bucket.

Backup-Storage: S3 und Alternativen

Velero unterstützt mehrere Storage-Backends über Provider-Plugins:

AWS S3 ist die einfachste Option für Cloud-Setups. Aktivieren Sie Versioning und Lifecycle-Policies auf dem Bucket:

# S3-Bucket mit Versioning (AWS CLI)
aws s3api create-bucket \
  --bucket kubernetes-backups \
  --region eu-central-1 \
  --create-bucket-configuration LocationConstraint=eu-central-1

aws s3api put-bucket-versioning \
  --bucket kubernetes-backups \
  --versioning-configuration Status=Enabled

MinIO für On-Premises. Gleiche S3-API, aber selbst gehostet. Ideal wenn Daten das Unternehmensnetzwerk nicht verlassen dürfen.

GCS und Azure Blob werden über eigene Plugins unterstützt (velero-plugin-for-gcp, velero-plugin-for-microsoft-azure).

Unabhängig vom Backend: Verschlüsseln Sie den Bucket. Velero selbst verschlüsselt keine Daten — das ist Aufgabe des Storage-Layers.

Restore-Prozeduren

Ein Backup ohne getesteten Restore ist nur eine Hoffnung. Hier die wichtigsten Szenarien.

Kompletter Namespace-Restore

# Verfügbare Backups auflisten
velero backup get

# Restore aus spezifischem Backup
velero restore create --from-backup daily-production-20260310020000

# Restore-Status prüfen
velero restore get
velero restore describe daily-production-20260310020000-restore --details

Restore in einen anderen Namespace

Nützlich, um ein Backup zu validieren, ohne die Produktion zu beeinflussen:

velero restore create prod-test-restore \
  --from-backup daily-production-20260310020000 \
  --include-namespaces production \
  --namespace-mappings production:production-test

Einzelne Ressourcen wiederherstellen

# Nur Deployments und ConfigMaps
velero restore create selective-restore \
  --from-backup daily-production-20260310020000 \
  --include-resources deployments,configmaps \
  --include-namespaces production

Disaster-Recovery-Test: Schritt für Schritt

DR-Tests sollten monatlich stattfinden. Hier ein konkreter Ablauf, den Sie als Runbook verwenden können.

#!/bin/bash
# dr-test.sh — Monatlicher DR-Test für Kubernetes-Backups
set -euo pipefail

BACKUP_NAME=$(velero backup get -o json | jq -r '.items | sort_by(.metadata.creationTimestamp) | last | .metadata.name')
TEST_NS="dr-test-$(date +%Y%m%d)"
echo "Verwende Backup: ${BACKUP_NAME}"
echo "Test-Namespace: ${TEST_NS}"

# 1. Restore in Test-Namespace
velero restore create dr-test-${TEST_NS} \
  --from-backup ${BACKUP_NAME} \
  --include-namespaces production \
  --namespace-mappings production:${TEST_NS}

# 2. Warten bis Restore abgeschlossen
echo "Warte auf Restore..."
while true; do
  PHASE=$(velero restore get dr-test-${TEST_NS} -o json | jq -r '.status.phase')
  [ "$PHASE" = "Completed" ] && break
  [ "$PHASE" = "Failed" ] && echo "RESTORE FAILED" && exit 1
  sleep 5
done

# 3. Pods prüfen
echo "Prüfe Pods im Test-Namespace..."
kubectl get pods -n ${TEST_NS}
kubectl wait --for=condition=Ready pods --all -n ${TEST_NS} --timeout=300s

# 4. Ergebnis
READY_PODS=$(kubectl get pods -n ${TEST_NS} --no-headers | grep -c "Running")
echo "DR-Test abgeschlossen: ${READY_PODS} Pods laufen in ${TEST_NS}"

# 5. Aufräumen (optional, manuell bestätigen)
echo "Test-Namespace aufräumen mit: kubectl delete namespace ${TEST_NS}"

Führen Sie dieses Script monatlich aus. Dokumentieren Sie das Ergebnis. Wenn der Restore fehlschlägt, wissen Sie es lieber jetzt als im Ernstfall.

Persistent Volumes sichern

Standardmäßig sichert Velero nur Kubernetes-Manifeste — nicht die Daten in Persistent Volumes. Für PV-Backups gibt es zwei Wege:

File-System-Backup (Kopia): Velero kopiert Dateien aus dem Volume über einen Node-Agent. Funktioniert mit jedem Storage-Backend.

# Velero mit File-System-Backup installieren
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.11.0 \
  --bucket kubernetes-backups \
  --secret-file /tmp/velero-credentials \
  --backup-storage-location-config region=eu-central-1,s3ForcePathStyle=true \
  --use-node-agent \
  --default-volumes-to-fs-backup \
  --namespace velero

CSI-Snapshots: Schneller, aber abhängig vom Storage-Provider. Funktioniert nur, wenn der CSI-Driver Volume-Snapshots unterstützt.

Für die meisten Teams ist File-System-Backup der pragmatischere Einstieg.

FAQ

Wie oft sollte ich Backups erstellen?

Hängt von der Recovery Point Objective (RPO) ab. Bei RPO von 24 Stunden reichen tägliche Backups. Bei RPO von 1 Stunde brauchen Sie stündliche Schedules. Bedenken Sie: Häufigere Backups bedeuten mehr Storage-Kosten und API-Server-Last.

Was passiert, wenn der S3-Bucket nicht erreichbar ist?

Velero markiert das Backup als "Failed". Bestehende Backups im Bucket bleiben erhalten. Velero versucht beim nächsten Schedule-Lauf erneut. Überwachen Sie die BackupStorageLocation — der Status sollte immer "Available" sein.

Kann ich Backups clusterübergreifend wiederherstellen?

Ja. Installieren Sie Velero im Ziel-Cluster mit denselben Storage-Credentials. Velero erkennt alle Backups im Bucket automatisch. Achten Sie darauf, dass CRDs im Ziel-Cluster vorhanden sind, sonst schlägt der Restore für Custom Resources fehl.

Wie groß werden die Backups?

Kubernetes-Manifeste sind komprimiert typischerweise wenige MB pro Namespace. PV-Daten über File-System-Backup entsprechen der tatsächlichen Datenmenge. Ein Namespace mit 100 Ressourcen ohne PV-Daten belegt etwa 2-5 MB.

Sichert Velero auch Secrets und ConfigMaps?

Ja, standardmäßig werden alle Namespace-Ressourcen gesichert — inklusive Secrets. Die Secrets liegen dann Base64-kodiert im Backup. Stellen Sie sicher, dass der S3-Bucket verschlüsselt und zugriffsbeschränkt ist.