Backup und Wiederherstellung im Cluster verlässlich aufsetzen lassen? WZ-IT plant, baut und betreibt Kubernetes-Cluster inklusive Backup, Restore-Tests und definierter Wiederherstellungsziele - auf Proxmox, Bare Metal und europäischer Infrastruktur. Managed Kubernetes ansehen
„Wir haben doch Snapshots" ist der häufigste Irrtum beim Kubernetes-Backup. Ein Snapshot sichert einen Zeitpunkt eines Datenträgers - aber ein Cluster besteht aus mehreren Ebenen, die getrennt geschützt werden müssen. Dieser Leitfaden zeigt die vier Ebenen eines vollständigen Backups, welche Werkzeuge welche abdecken, und warum am Ende nur der getestete Restore zählt. Stand Juli 2026.
Inhaltsverzeichnis
- Warum Snapshot nicht gleich Backup ist
- Die vier Ebenen, die getrennt geschützt werden
- Ebene 1: etcd, der Cluster-Zustand
- Ebene 2 und 3: Ressourcen und Volumes mit Velero
- Ebene 4: anwendungskonsistente Datenbank-Backups
- Der getestete Restore entscheidet
Warum Snapshot nicht gleich Backup ist
Ein VM- oder Volume-Snapshot ist wertvoll, aber er beantwortet nur eine von mehreren Fragen. Er hält einen Zeitpunkt der Datenträger fest - nicht aber automatisch einen konsistenten Zustand der Control Plane, die versionierte Definition des Clusters oder eine transaktional saubere Datenbank. Und er schützt nicht vor den häufigsten Verlustursachen: versehentliches Löschen, ein fehlerhaftes Deployment oder Ransomware werden bei reiner Replikation sogar mitrepliziert.
Ein belastbares Backup schützt deshalb mehrere Ebenen getrennt und legt sie auf einem eigenen Pfad und Ziel ab. Genau diese Trennung ist der Unterschied zwischen „wir haben Snapshots" und „wir können den Cluster wiederherstellen".
Die vier Ebenen, die getrennt geschützt werden
Ein vollständiges Kubernetes-Backup deckt vier Ebenen ab, die je eigene Werkzeuge und Rhythmen brauchen:
- etcd - der gesamte Zustand des Clusters (nur bei self-hosted relevant).
- Cluster-Ressourcen - die Objekte, die den Soll-Zustand beschreiben (Deployments, Services, ConfigMaps, Secrets).
- Persistente Volumes - die eigentlichen Daten der Anwendungen.
- Anwendungskonsistente Datenbanken - ein transaktional sauberer Stand der Datenbank-Inhalte.
Wer nur eine dieser Ebenen sichert, hat kein Backup, sondern einen Teilaspekt. Im Folgenden, was jede Ebene abdeckt und womit.
Ebene 1: etcd, der Cluster-Zustand
etcd ist die Datenbank der Control Plane und hält den kompletten Zustand des Clusters. Fällt sie unrettbar aus, ist der Cluster verloren - selbst wenn alle Nodes laufen. Für self-hosted Cluster ist ein regelmäßiger etcd-Snapshot (etcdctl snapshot save) daher die Basis jeder Wiederherstellung; die Kubernetes-Dokumentation beschreibt das Sichern und Zurückspielen.
Bei Managed-Kubernetes-Diensten übernimmt der Anbieter diese Ebene. Bei selbst betriebenen Clustern - der Regelfall auf Proxmox oder Bare Metal - liegt sie in Ihrer Verantwortung und wird beim Aufbau oft übersehen.
Ebene 2 und 3: Ressourcen und Volumes mit Velero
Velero ist das etablierte Werkzeug für die beiden mittleren Ebenen. Es sichert Kubernetes-Ressourcen (über die API abgefragte Cluster-Objekte) und persistente Volumes nach Objekt-Storage, läuft geplant, kann gezielt wiederherstellen und ganze Anwendungen zwischen Clustern migrieren.
Damit deckt Velero den Soll-Zustand (Ebene 2) und die Nutzdaten (Ebene 3) in einem Werkzeug ab - inklusive CSI-Snapshots der Volumes. Wichtig ist das Ziel: Der Backup-Speicher (S3-kompatibel) muss getrennt vom Cluster liegen, damit ein Cluster-Ausfall das Backup nicht mitnimmt. Storage-Systeme wie Longhorn ergänzen das um eigene inkrementelle Backups der Volumes nach NFS oder S3.
Ebene 4: anwendungskonsistente Datenbank-Backups
Die Ebene, an der die meisten Konzepte scheitern: Ein Volume-Snapshot einer laufenden Datenbank ist nicht zwingend konsistent - er kann mitten in einer Transaktion entstehen. Für einen verlässlichen Restore braucht es anwendungskonsistente Backups: native Dumps (pg_dump, mysqldump) oder das Backup-Werkzeug der jeweiligen Datenbank, ausgelöst in einem sauberen Zustand.
Velero kann diese Schritte über Pre- und Post-Hooks orchestrieren, sodass der Snapshot zu einem konsistenten Zeitpunkt entsteht. Entscheidend ist, diese Ebene bewusst zu planen - sie ist nicht durch die Volume-Sicherung der Ebene 3 mit abgedeckt.
Der getestete Restore entscheidet
Alle vier Ebenen zu sichern nützt wenig, wenn niemand die Wiederherstellung geprüft hat. Der häufigste kritische Befund bei der Übernahme fremder Cluster ist ein nie getesteter Restore: Backups existieren, aber niemand hat je eine vollständige Wiederherstellung durchgespielt. Ein Backup, das nie zurückgespielt wurde, ist im Ernstfall eine Vermutung, kein Sicherheitsnetz.
Ein belastbares Konzept prüft daher mindestens einmal pro Quartal einen vollständigen Restore der kritischen Ebenen - inklusive Datenbank - und passt die Wiederherstellungsziele (RPO, RTO) an die Geschäftskritikalität an. Wie dieser Punkt in die Bewertung eines bestehenden Clusters einfließt, zeigt der Übernahme-Audit; welches Storage-System die Volumes trägt, ordnet Longhorn vs. Rook-Ceph ein.
