Kubernetes Backup fuer den Mittelstand: Was passiert, wenn Ihr Cluster ausfaellt?

TL;DR

• Ohne getestetes Backup ist es kein Backup. 67% der Unternehmen, die ihre DR-Strategie nie testen, schaffen die Wiederherstellung im Ernstfall nicht innerhalb der zugesagten RTO.
• Velero ist der De-facto-Standard fuer Kubernetes-Backups: Open Source, CNCF Sandbox, unterstuetzt alle grossen Cloud-Provider und On-Premises-Storage.
• RPO und RTO muessen vom Business definiert werden, nicht von der IT. Ein Online-Shop hat andere Anforderungen als ein internes ERP-System.
• DSGVO erfordert Loeschfaehigkeit auch in Backups. Wer personenbezogene Daten sichert, muss sie auch im Backup gezielt loeschen koennen -- oder die Retention so kurz halten, dass Loeschanfragen durch Ablauf abgedeckt sind.
• DR-Tests gehoeren in den Kalender: Mindestens quartalsweise, idealerweise monatlich, automatisiert wo moeglich.

Das Szenario: Montagmorgen, 07:15 Uhr

Ihr DevOps-Engineer kommt ins Buero. Die Monitoring-Alerts sind rot. Der Production-Cluster antwortet nicht. Ein fehlgeschlagenes Upgrade hat den etcd-Cluster beschaedigt. Alle Deployments, Services, ConfigMaps -- weg.

Die Frage, die jetzt zaehlt: Haben Sie ein Backup? Und wenn ja -- haben Sie es jemals getestet?

Fuer viele Mittelstandsunternehmen endet dieses Szenario mit Tagen Ausfallzeit, manueller Rekonstruktion aus Git-Repos und einem sehr unangenehmen Meeting mit der Geschaeftsfuehrung. Das muss nicht sein.

RPO und RTO: Die zwei Zahlen, die alles bestimmen

Bevor Sie ein Backup-Tool installieren, muessen zwei Fragen beantwortet werden:

• RPO (Recovery Point Objective): Wie viel Datenverlust ist akzeptabel? Ein RPO von 1 Stunde bedeutet: Im schlimmsten Fall verlieren Sie die Aenderungen der letzten 60 Minuten.
• RTO (Recovery Time Objective): Wie lange darf die Wiederherstellung dauern? Ein RTO von 2 Stunden bedeutet: Nach 2 Stunden muss alles wieder laufen.

RPO/RTO-Matrix fuer typische Mittelstands-Workloads

Die Kosten steigen mit strengerem RPO/RTO. Nicht jeder Workload braucht die gleiche Strategie. Definieren Sie mit dem Fachbereich, was wirklich geschaeftskritisch ist.

Velero: Der Standard fuer Kubernetes-Backups

Velero (ehemals Heptio Ark) ist ein CNCF-Sandbox-Projekt und der am weitesten verbreitete Backup-Ansatz fuer Kubernetes. Es sichert:

• Kubernetes-Ressourcen: Deployments, Services, ConfigMaps, Secrets, CRDs -- alles, was im API-Server lebt
• Persistent Volumes: Ueber Cloud-Provider-Snapshots (EBS, Azure Disk, GCE PD) oder Restic/Kopia fuer Filesystem-Level-Backups
• Namespaces: Granulare Backups pro Namespace oder Cluster-weit

Velero installieren und konfigurieren

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

# Velero mit AWS S3-Backend installieren
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.11.0 \
  --bucket kubernetes-backups-prod \
  --backup-location-config region=eu-central-1 \
  --snapshot-location-config region=eu-central-1 \
  --secret-file ./credentials-velero \
  --use-node-agent \
  --default-volumes-to-fs-backup

# Fuer Azure:
# velero install \
#   --provider azure \
#   --plugins velero/velero-plugin-for-microsoft-azure:v1.11.0 \
#   --bucket kubernetes-backups-prod \
#   --secret-file ./credentials-velero \
#   --backup-location-config resourceGroup=backup-rg,storageAccount=k8sbackups \
#   --use-node-agent

Automatische Backups einrichten

# velero-schedule-production.yaml
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: production-backup-hourly
  namespace: velero
spec:
  schedule: "0 * * * *"  # Jede Stunde
  template:
    includedNamespaces:
      - production
      - database
    excludedResources:
      - events
      - events.events.k8s.io
    storageLocation: default
    volumeSnapshotLocations:
      - default
    ttl: 168h  # 7 Tage Retention
    defaultVolumesToFsBackup: true
    metadata:
      labels:
        backup-type: scheduled
        environment: production

---
# Taegliches Full-Cluster-Backup
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: full-cluster-backup-daily
  namespace: velero
spec:
  schedule: "0 2 * * *"  # Taeglich um 02:00 Uhr
  template:
    excludedResources:
      - events
      - events.events.k8s.io
    storageLocation: default
    volumeSnapshotLocations:
      - default
    ttl: 720h  # 30 Tage Retention
    defaultVolumesToFsBackup: true
    metadata:
      labels:
        backup-type: full-daily

Restore testen

Ein Backup, das nie getestet wurde, ist kein Backup. So testen Sie einen Restore:

# Backup auflisten
velero backup get

# Restore in einen separaten Namespace (ohne Production zu beeinflussen)
velero restore create test-restore-$(date +%Y%m%d) \
  --from-backup production-backup-hourly-20260210080000 \
  --namespace-mappings production:restore-test \
  --restore-volumes=true

# Status pruefen
velero restore describe test-restore-20260210

# Ergebnis validieren
kubectl get pods -n restore-test
kubectl get pvc -n restore-test

# Test-Namespace aufraeumen
kubectl delete namespace restore-test

etcd-Backup: Die Lebensversicherung fuer Self-Managed Cluster

Wer Kubernetes nicht als Managed Service (EKS, AKS, GKE) betreibt, muss etcd separat sichern. etcd speichert den gesamten Cluster-State -- ohne etcd existiert der Cluster nicht mehr.

# etcd-Snapshot erstellen (auf einem Control-Plane Node)
ETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-$(date +%Y%m%d-%H%M).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-Integritaet pruefen
ETCDCTL_API=3 etcdctl snapshot status /tmp/etcd-$(date +%Y%m%d-%H%M).db --write-out=table

# Automatisierung per CronJob auf dem Host
# 0 */2 * * * /usr/local/bin/etcd-backup.sh && \
#   aws s3 cp /tmp/etcd-latest.db s3://etcd-backups/$(hostname)/

Fuer Managed Kubernetes (EKS, AKS, GKE) uebernimmt der Cloud-Provider das etcd-Management. Velero reicht dort als Backup-Loesung in den meisten Faellen aus.

DSGVO-konformes Backup: Was viele uebersehen

Backups enthalten Daten. Wenn diese Daten personenbezogen sind, greift die DSGVO. Das hat konkrete Konsequenzen fuer Ihre Backup-Strategie:

Die drei DSGVO-Anforderungen an Backups

Verschluesselung konfigurieren

Velero mit Kopia (ab v1.12) unterstuetzt serverseitige Verschluesselung:

# S3-Backend mit SSE-KMS Verschluesselung
velero backup-location create encrypted-backups \
  --provider aws \
  --bucket kubernetes-backups-encrypted \
  --config region=eu-central-1,serverSideEncryption=aws:kms,kmsKeyId=arn:aws:kms:eu-central-1:123456789:key/backup-key

Retention-Strategie fuer DSGVO-Konformitaet

Die einfachste Loesung fuer Art. 17 (Recht auf Loeschung): Halten Sie die Backup-Retention so kurz wie moeglich. Wenn Backups nach 30 Tagen automatisch geloescht werden, ist eine Loeschanfrage nach spaetestens 30 Tagen durch Ablauf erfuellt -- dokumentieren Sie das in Ihrem Verarbeitungsverzeichnis.

DR-Testing: Der vergessene Schritt

Eine Backup-Strategie ohne Tests ist Theorie. In der Praxis scheitern Restores an Problemen, die vorher niemand bedacht hat: fehlende Secrets, inkompatible CRD-Versionen, Storage-Klassen die im Zielcluster nicht existieren.

DR-Test-Checkliste

Vorbereitung (einmalig):

• Separaten Test-Cluster oder Test-Namespace bereitstellen
• Restore-Runbook dokumentieren (wer macht was in welcher Reihenfolge)
• Erfolgskriterien definieren (welche Services muessen nach dem Restore funktionieren)

Durchfuehrung (quartalsweise):

1. Aktuelles Backup auswaehlen
2. Restore in Test-Umgebung durchfuehren
3. Alle definierten Services pruefen (Health-Checks, Smoke-Tests)
4. RTO messen: Wie lange hat der Restore gedauert?
5. RPO validieren: Sind die Daten vollstaendig und aktuell?
6. Ergebnisse dokumentieren und Abweichungen als Tickets erfassen

Automatisierung (Ziel):

# Einfaches DR-Test-Script (ausfuehren per CronJob oder CI/CD)
#!/bin/bash
set -euo pipefail

BACKUP_NAME=$(velero backup get -o json | jq -r '.items | sort_by(.metadata.creationTimestamp) | last | .metadata.name')
RESTORE_NS="dr-test-$(date +%Y%m%d)"
TIMESTAMP_START=$(date +%s)

echo "Starte DR-Test mit Backup: $BACKUP_NAME"

# Restore durchfuehren
velero restore create "dr-test-${BACKUP_NAME}" \
  --from-backup "$BACKUP_NAME" \
  --namespace-mappings "production:${RESTORE_NS}" \
  --restore-volumes=true \
  --wait

# Warten bis Pods ready sind (Timeout 10 Minuten)
kubectl wait --for=condition=ready pod \
  --all -n "$RESTORE_NS" \
  --timeout=600s

TIMESTAMP_END=$(date +%s)
DURATION=$((TIMESTAMP_END - TIMESTAMP_START))

echo "DR-Test abgeschlossen in ${DURATION} Sekunden"
echo "RTO-Messung: ${DURATION}s"

# Health-Check der wichtigsten Services
kubectl get pods -n "$RESTORE_NS" --no-headers | \
  awk '{print $3}' | sort | uniq -c

# Aufraeumen
kubectl delete namespace "$RESTORE_NS"

Backup-Strategie nach Clustergröße

Nicht jedes Unternehmen braucht die gleiche Backup-Strategie. Hier eine Orientierung nach Unternehmensgroesse:

Kleiner Mittelstand (1-2 Cluster, unter 20 Nodes)

Mittlerer Mittelstand (3-5 Cluster, 20-100 Nodes)

Gehobener Mittelstand (5+ Cluster, 100+ Nodes)

Die 5 haeufigsten Backup-Fehler im Mittelstand

1. Kein Backup der Persistent Volumes. Velero sichert standardmaessig nur Kubernetes-Ressourcen, nicht den Inhalt der PVs. Ohne --default-volumes-to-fs-backup oder Cloud-Provider-Snapshots sind Ihre Daten nicht gesichert.

2. Secrets nicht im Backup. Manche Teams excluden den Namespace kube-system oder Secrets generell. Nach dem Restore funktioniert nichts mehr, weil TLS-Zertifikate, Datenbank-Passwoerter und API-Keys fehlen.

3. Backup nur in derselben Region. Wenn die gesamte Region ausfaellt, ist auch das Backup weg. Cross-Region-Replication fuer den Backup-Bucket ist Pflicht.

4. Nie getestet. Der haeufigste und teuerste Fehler. Ein Backup, das nie restored wurde, ist eine Hoffnung, kein Backup.

5. Keine Alerting bei Backup-Fehlern. Velero-Backups koennen fehlschlagen (Storage voll, Credentials abgelaufen, Timeout). Ohne Monitoring bemerken Sie das erst im Ernstfall.

Fazit: Backup ist keine Kuer, sondern Pflicht

Ein Kubernetes-Cluster ohne Backup-Strategie ist wie ein Auto ohne Versicherung: Es geht gut, bis es nicht mehr gut geht. Und dann wird es richtig teuer.

Die gute Nachricht: Mit Velero, einem S3-Bucket und einem getesteten Restore-Prozess haben Sie in einer Woche eine solide Grundlage. Die Kosten sind ueberschaubar, der Schutz ist erheblich.

Fangen Sie heute an. Nicht naechste Woche.

Weiterfuehrende Artikel

• Kubernetes Disaster Recovery: RPO, RTO und Failover-Strategien -- Vertiefte DR-Konzepte mit Multi-Cluster-Failover
• Kubernetes Kosten senken: 10 Praxis-Tipps -- Kosten optimieren, auch beim Backup-Storage
• Kubernetes DSGVO-Compliance: 7-Punkte Checkliste -- DSGVO-Anforderungen im Detail
• 24/7 Kubernetes-Betrieb im Mittelstand -- Was passiert, wenn der Ausfall nachts um 3 kommt
• NIS2-Audit bestehen: Was Pruefer wirklich sehen wollen -- Backup als Audit-Anforderung