etcd Backup und Wartung: Kubernetes-Datenbank sichern

TL;DR

etcd speichert den gesamten Cluster-State -- jedes Deployment, jeden Service, jedes Secret. Ohne funktionierendes etcd-Backup ist ein Cluster nach einem Ausfall nicht wiederherstellbar. Mit etcdctl snapshot save lassen sich konsistente Backups erzeugen, die per CronJob automatisiert und mit regelmässiger Defragmentierung kombiniert werden sollten. Dieser Guide zeigt den kompletten Workflow von Backup bis Restore.

Warum etcd-Backups ueberlebenswichtig sind

etcd ist die einzige Datenquelle fuer den gesamten Kubernetes-Cluster-State. Faellt etcd aus oder werden Daten korrupt, sind alle Ressourcen-Definitionen verloren -- Deployments, Services, ConfigMaps, Secrets, RBAC-Regeln. Der Cluster ist faktisch tot.

Managed Kubernetes-Dienste wie EKS, AKS oder GKE kuemmern sich automatisch um etcd. Wer aber Self-Managed Cluster betreibt (kubeadm, k3s, Rancher), traegt die volle Verantwortung fuer Backup und Wartung.

# etcd-Version und Cluster-Status pruefen
etcdctl version

# Endpoint-Status anzeigen
ETCDCTL_API=3 etcdctl \
  --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 \
  endpoint status --write-out=table

Die Ausgabe zeigt DB-Groesse, Raft-Index und Leader-Status -- wichtige Indikatoren fuer die Cluster-Gesundheit.

Snapshot erstellen mit etcdctl

Ein etcd-Snapshot ist ein konsistenter Abzug der gesamten Datenbank zu einem bestimmten Zeitpunkt.

# Snapshot erstellen
ETCDCTL_API=3 etcdctl \
  --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 save /backup/etcd-snapshot-$(date +%Y%m%d-%H%M%S).db

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

Feld	Bedeutung
Hash	Integritaets-Hash des Snapshots
Revision	Letzte Raft-Revision im Snapshot
Total Keys	Anzahl gespeicherter Keys
Total Size	Groesse der Datenbank

Wichtig: Snapshots immer auf einem separaten Volume oder externem Storage ablegen -- nicht auf dem gleichen Disk wie etcd selbst.

Automatisiertes Backup per CronJob

Manuelle Backups vergisst man. Ein Kubernetes CronJob automatisiert den Prozess:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: etcd-backup
  namespace: kube-system
spec:
  schedule: "0 */6 * * *"  # Alle 6 Stunden
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  jobTemplate:
    spec:
      template:
        spec:
          hostNetwork: true
          nodeSelector:
            node-role.kubernetes.io/control-plane: ""
          tolerations:
            - effect: NoSchedule
              operator: Exists
          containers:
            - name: etcd-backup
              image: registry.k8s.io/etcd:3.5.12-0
              command:
                - /bin/sh
                - -c
                - |
                  STAMP=$(date +%Y%m%d-%H%M%S)
                  etcdctl \
                    --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 save /backup/etcd-${STAMP}.db
                  # Alte Backups aufräumen (älter als 7 Tage)
                  find /backup -name "etcd-*.db" -mtime +7 -delete
                  echo "Backup etcd-${STAMP}.db erstellt"
              env:
                - name: ETCDCTL_API
                  value: "3"
              volumeMounts:
                - name: etcd-certs
                  mountPath: /etc/kubernetes/pki/etcd
                  readOnly: true
                - name: backup-volume
                  mountPath: /backup
          restartPolicy: OnFailure
          volumes:
            - name: etcd-certs
              hostPath:
                path: /etc/kubernetes/pki/etcd
            - name: backup-volume
              persistentVolumeClaim:
                claimName: etcd-backup-pvc

Der CronJob laeuft alle 6 Stunden auf einem Control-Plane-Node und loescht automatisch Backups, die aelter als 7 Tage sind.

Health Checks und Monitoring

Regelmässige Health Checks erkennen Probleme, bevor sie kritisch werden:

# Endpoint-Health pruefen
ETCDCTL_API=3 etcdctl \
  --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 \
  endpoint health --write-out=table

# Alarm-Liste anzeigen (NOSPACE, CORRUPT)
ETCDCTL_API=3 etcdctl \
  --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 \
  alarm list

Kritische Metriken fuer Prometheus/Grafana:

Metrik	Warnschwelle	Bedeutung
`etcd_server_has_leader`	0	Kein Leader gewaehlt -- Cluster blockiert
`etcd_disk_wal_fsync_duration_seconds`	> 10ms (p99)	Disk zu langsam fuer etcd
`etcd_mvcc_db_total_size_in_bytes`	> 6 GB	DB naehert sich dem Limit (Standard: 8 GB)
`etcd_network_peer_round_trip_time_seconds`	> 50ms	Netzwerk-Latenz zwischen etcd-Membern zu hoch

Defragmentierung

etcd gibt Speicher nach dem Loeschen von Keys nicht automatisch frei. Ueber die Zeit waechst die DB-Datei, obwohl weniger Daten gespeichert sind. Defragmentierung loest das:

# DB-Groesse vor Defragmentierung pruefen
ETCDCTL_API=3 etcdctl \
  --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 \
  endpoint status --write-out=table

# Defragmentierung ausfuehren (pro Member, NICHT parallel)
ETCDCTL_API=3 etcdctl \
  --endpoints=https://etcd-node-1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  defrag

# Danach: DB-Groesse erneut pruefen

Wichtig: Defragmentierung blockiert den betroffenen Member kurzzeitig. In einem Multi-Member-Cluster immer einzeln defragmentieren -- zuerst Follower, dann Leader. Nie alle gleichzeitig.

Performance Tuning

etcd ist extrem empfindlich gegenueber Disk-Latenz. SSDs sind Pflicht, HDDs fuehren unweigerlich zu Problemen.

# Disk-Performance testen (Ziel: < 10ms fuer WAL fsync)
fio --rw=write --ioengine=sync --fdatasync=1 \
  --directory=/var/lib/etcd --size=22m \
  --bs=2300 --name=etcd-perf

# etcd-Konfiguration fuer bessere Performance
# In /etc/kubernetes/manifests/etcd.yaml ergänzen:
# --heartbeat-interval=250
# --election-timeout=2500
# --snapshot-count=5000
# --quota-backend-bytes=8589934592

Faustregel: Die Disk-Latenz fuer WAL-fsync sollte unter 10ms liegen (p99). Alles darueber fuehrt zu Leader-Elections und instabilem Cluster-Verhalten.

Disaster Recovery: Snapshot Restore

Der entscheidende Moment -- der Cluster ist ausgefallen und muss aus einem Snapshot wiederhergestellt werden:

# Schritt 1: etcd stoppen (bei kubeadm: Static Pod Manifest verschieben)
mv /etc/kubernetes/manifests/etcd.yaml /tmp/etcd.yaml.bak

# Schritt 2: Altes Datenverzeichnis sichern
mv /var/lib/etcd /var/lib/etcd.old

# Schritt 3: Snapshot wiederherstellen
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-20260310-140000.db \
  --data-dir=/var/lib/etcd \
  --name=master-1 \
  --initial-cluster=master-1=https://10.0.1.10:2380 \
  --initial-cluster-token=etcd-cluster-1 \
  --initial-advertise-peer-urls=https://10.0.1.10:2380

# Schritt 4: etcd wieder starten
mv /tmp/etcd.yaml.bak /etc/kubernetes/manifests/etcd.yaml

# Schritt 5: Cluster-Status pruefen
kubectl get nodes
kubectl get pods --all-namespaces

Bei einem Multi-Node etcd-Cluster muss der Restore auf allen Membern gleichzeitig durchgefuehrt werden -- mit den jeweiligen Member-Namen und Peer-URLs.

Backup-Strategie: Zusammenfassung

Ein solides etcd-Backup-Konzept kombiniert mehrere Ebenen:

Automatisierte Snapshots per CronJob alle 4-6 Stunden
Off-Site-Kopie der Snapshots auf S3, GCS oder separatem Storage
Regelmaessige Restore-Tests -- ein Backup, das nie getestet wurde, ist kein Backup
Monitoring der etcd-Metriken mit Alerting bei kritischen Schwellwerten
Defragmentierung woechentlich oder bei DB-Groesse > 50% des Quotas

FAQ

Wie oft sollte ich etcd-Backups erstellen?

Alle 4-6 Stunden ist ein guter Richtwert. Bei Clustern mit haeufigen Aenderungen (GitOps, viele Deployments pro Tag) kann ein kuerzeres Intervall von 1-2 Stunden sinnvoll sein. Entscheidend ist: Wie viel State koennt ihr maximal verlieren?

Kann ich etcd-Backups im laufenden Betrieb erstellen?

Ja. etcdctl snapshot save erstellt einen konsistenten Snapshot ohne den Cluster zu stoppen. Die Operation ist non-blocking und hat minimalen Performance-Impact. Trotzdem sollte sie nicht waehrend Peak-Zeiten laufen.

Was passiert bei einem Restore mit Ressourcen, die nach dem Snapshot erstellt wurden?

Alle Aenderungen nach dem Snapshot-Zeitpunkt gehen verloren. Pods, die nach dem Snapshot erstellt wurden, existieren physisch noch auf den Nodes, sind aber im API-Server unbekannt. Kubernetes raeumt diese verwaisten Container nach dem Restore automatisch auf.

Brauche ich etcd-Backups bei Managed Kubernetes (EKS, AKS, GKE)?

Nein. Bei Managed Services verwaltet der Cloud-Provider etcd vollstaendig inklusive Backups. Ihr habt keinen direkten Zugriff auf etcd. Trotzdem solltet ihr Kubernetes-Ressourcen per Velero oder GitOps sichern -- als zusaetzliche Absicherung.

Wie teste ich, ob ein etcd-Snapshot funktioniert?

Am besten mit einem separaten Test-Cluster. Snapshot auf einem isolierten Node wiederherstellen, etcd starten und pruefen, ob alle erwarteten Keys vorhanden sind. Diesen Test mindestens quartalsweise durchfuehren.

Kubernetes ohne DevOps-Overhead?

Wir betreiben Ihre Kubernetes-Cluster 24/7 – Sie fokussieren auf Ihr Kerngeschäft. Ab 4.000€/Monat, DSGVO-konform, mit deutschem Support.

24/7 SupportDeutsche RechenzentrenDSGVO-konform

Kostenlose Erstberatung Kontakt aufnehmen

etcd Backup und Wartung: Kubernetes-Datenbank sichern

etcd Backup und Wartung: Kubernetes-Datenbank sichern

TL;DR

Warum etcd-Backups ueberlebenswichtig sind

Snapshot erstellen mit etcdctl

Automatisiertes Backup per CronJob

Health Checks und Monitoring

Defragmentierung

Performance Tuning

Disaster Recovery: Snapshot Restore

Backup-Strategie: Zusammenfassung

FAQ

Wie oft sollte ich etcd-Backups erstellen?

Kann ich etcd-Backups im laufenden Betrieb erstellen?

Was passiert bei einem Restore mit Ressourcen, die nach dem Snapshot erstellt wurden?

Brauche ich etcd-Backups bei Managed Kubernetes (EKS, AKS, GKE)?

Wie teste ich, ob ein etcd-Snapshot funktioniert?

Kubernetes ohne DevOps-Overhead?

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

Velero Backup: Kubernetes-Cluster richtig sichern

Disaster Recovery für Kubernetes-Cluster planen

Kubernetes Backup mit Velero: Disaster Recovery Praxis

Kubernetes Disaster Recovery: RPO, RTO und Failover-Strategien

Velero Backup mit MinIO: Kubernetes Cluster sichern