Kubernetes Backup
Gefährliche Backup-Lücke: Warum gesicherte Kubernetes-Daten im Ernstfall nicht ausreichen
Kubernetes-Datensicherung: Fünf Herausforderungen und drei Fehler, die Unternehmen vermeiden sollten
Cloud-native Anwendungen stellen Unternehmen vor neue Herausforderungen bei der Datensicherung. Während klassische Backup-Lösungen vor allem virtuelle Maschinen und Speicherbereiche schützen, erfordert Kubernetes einen grundlegend anderen Ansatz. HYCU erläutert, warum die ausschließliche Sicherung von Persistent Volumes oder virtuellen Maschinen im Ernstfall nicht ausreicht und welche Voraussetzungen eine vollständige Wiederherstellung containerisierter Anwendungen erfüllen muss.
Ein typisches Szenario aus der Unternehmenspraxis verdeutlicht das Problem: Sämtliche Nodes eines Kubernetes-Clusters werden regelmäßig über VM-Backups gesichert. Die IT-Verantwortlichen gehen davon aus, dass damit auch die darauf betriebenen Anwendungen ausreichend geschützt sind.
Doch im Ernstfall zeigt sich eine entscheidende Lücke. Zwar lassen sich die virtuellen Maschinen wiederherstellen, wichtige Kubernetes-spezifische Informationen fehlen jedoch. Dazu gehören Namespace-Konfigurationen, YAML-Manifeste, ConfigMaps, Secrets und gegebenenfalls der etcd-Zustand, der dokumentiert, welche Ressourcen innerhalb des Clusters existieren sollen.
Das technische Fundament ist damit zwar gesichert, die eigentliche Anwendung lässt sich jedoch nicht ohne Weiteres wiederherstellen.
Nach Einschätzung von HYCU liegt genau darin eine der größten Schwachstellen vieler herkömmlicher Backup-Strategien. Kubernetes benötigt einen Schutzansatz, der nicht nur einzelne Infrastrukturkomponenten berücksichtigt, sondern die gesamte Workload einschließlich ihrer Konfigurationen, Abhängigkeiten und persistenten Daten erfasst.
Kubernetes-Backup muss die gesamte Workload berücksichtigen
Ein vollständiges Kubernetes-Backup umfasst weit mehr als die Sicherung laufender Container. Entscheidend ist, dass eine containerisierte Anwendung einschließlich ihres persistenten Zustands und ihrer Konfiguration wiederhergestellt werden kann – idealerweise nicht nur im ursprünglichen Cluster, sondern auch in einer anderen Kubernetes-Umgebung oder Cloud.
Dazu gehören Persistent Volumes, Namespaces, Deployment- und StatefulSet-Manifeste, ConfigMaps, Secrets, Custom Resource Definitions (CRDs) und gegebenenfalls der Zustand der Kubernetes-Control-Plane.
Die Herausforderung liegt im Zusammenspiel dieser Komponenten.
Wer ausschließlich Persistent Volumes sichert, kann zwar gespeicherte Daten zurückholen, besitzt aber möglicherweise nicht die notwendigen Informationen, um die Anwendung wieder in Betrieb zu nehmen. Werden dagegen nur YAML-Manifeste und Konfigurationsinformationen gesichert, lässt sich die ursprüngliche Struktur rekonstruieren, nicht jedoch der aktuelle Datenbestand.
Beide Ansätze sind in der Praxis verbreitet. Für eine vollständige Wiederherstellung reichen sie jedoch nicht aus.
Warum Container andere Backup-Strategien benötigen als virtuelle Maschinen
Virtuelle Maschinen und Container weisen technische Gemeinsamkeiten auf. Beide nutzen Virtualisierungskonzepte, unterstützen bestimmte Snapshot-Verfahren und können ihre Sicherungsdaten grundsätzlich in gemeinsamen Backup-Repositories ablegen. Die Unterschiede im Betriebsmodell sind allerdings erheblich. HYCU hebt insbesondere drei Eigenschaften hervor, die bei der Planung einer Kubernetes-Backup-Strategie berücksichtigt werden müssen.
1. Flüchtiger Speicher statt dauerhaft verfügbarer Daten
Während der Speicher einer virtuellen Maschine in der Regel auch nach dem Herunterfahren erhalten bleibt, ist dies bei Containern nicht grundsätzlich der Fall. Wird ein Pod beendet, können temporäre Speicherbereiche wie emptyDir-Volumes freigegeben werden. Daten, die ausschließlich dort gespeichert wurden, stehen anschließend möglicherweise nicht mehr zur Verfügung. Eine zuverlässige Backup-Strategie muss deshalb zwischen persistenten und flüchtigen Daten unterscheiden und sicherstellen, dass geschäftskritische Informationen rechtzeitig erfasst werden.
2. Dynamische Workloads statt stabiler Infrastruktur
Virtuelle Maschinen sind häufig über längere Zeiträume hinweg verfügbar. Kubernetes-Pods werden dagegen bewusst dynamisch betrieben. Sie entstehen, werden beendet, neu gestartet oder auf andere Nodes verschoben. Diese Veränderungen gehören zum regulären Betriebsmodell einer containerisierten Infrastruktur. Klassische Backup-Konzepte, die auf festen Systemzuordnungen und vorhersehbaren Sicherungsfenstern beruhen, stoßen dadurch schnell an ihre Grenzen.
3. Anwendungen bestehen aus mehreren Komponenten
Eine virtuelle Maschine kann eine vollständige Anwendung beherbergen. In Kubernetes verteilen sich Anwendungen dagegen häufig auf mehrere Pods und unterschiedliche Ressourcen.
Die relevante Sicherungseinheit ist deshalb nicht zwangsläufig der einzelne Pod. Häufig bilden ein Namespace, ein Helm-Release oder eine vom Operator verwaltete Ressourcengruppe die sinnvollere Grenze. Eine ausschließlich podbasierte Sicherung würde zusammengehörige Anwendungskomponenten voneinander trennen und die Wiederherstellung unnötig erschweren.
Fünf zentrale Herausforderungen beim Kubernetes-Backup
Die Analysten der Data Center Intelligence Group (DCIG) haben fünf Herausforderungen identifiziert, die moderne Backup-Lösungen für Kubernetes-Umgebungen bewältigen müssen. Sie verdeutlichen, weshalb sich Kubernetes-native Sicherungskonzepte von traditionellen Backup-Architekturen unterscheiden.
1. Flüchtige Daten müssen rechtzeitig gesichert werden
Container und Pods können eine deutlich kürzere Lebensdauer haben als klassische virtuelle Maschinen. Wird ein Pod beendet, können temporär gespeicherte Informationen verloren gehen. Eine Backup-Plattform muss daher relevante Anwendungen und Ressourcen automatisch erkennen und ihre Sicherung entsprechend dem tatsächlichen Lebenszyklus steuern. Die alleinige Orientierung an nächtlichen Backup-Fenstern ist problematisch. Eine Workload, die am Nachmittag gestartet wurde, kann bereits am Abend wieder verschwunden sein. Entscheidend ist deshalb eine kontinuierliche Erkennung schutzbedürftiger Ressourcen und die automatische Anwendung geeigneter Sicherungsrichtlinien.
2. Die Platzierung von Workloads ist dynamisch
In Kubernetes entscheidet der kube-scheduler anhand technischer Kriterien darüber, auf welchem Node ein Pod ausgeführt wird. Zu diesen Kriterien gehören unter anderem die Ressourcenverfügbarkeit, Affinitätsregeln sowie Taints und Tolerations. Für die Datensicherung bedeutet dies, dass sich Backup-Richtlinien nicht dauerhaft an einzelne Nodes binden lassen. Stattdessen muss der Schutz der jeweiligen Workload folgen – unabhängig davon, wo Kubernetes sie ausführt. Gleichzeitig benötigt nicht jeder Container dieselbe Sicherungsstrategie. Manche Anwendungen müssen regelmäßig geschützt werden, andere lediglich zu bestimmten Zeitpunkten ihres Lebenszyklus.
3. Skalierbarkeit wird zur betrieblichen Herausforderung
Produktive Kubernetes-Umgebungen können Tausende Pods in Hunderten Namespaces umfassen. In großen Multi-Cluster-Architekturen wächst die Zahl der verwalteten Ressourcen entsprechend weiter. Hinzu kommt die hohe Veränderungsgeschwindigkeit. Container werden erstellt, verändert und wieder entfernt, häufig innerhalb kurzer Zeiträume. Backup-Plattformen, die auf manuelle Registrierung, individuelle Richtlinienzuweisung und regelmäßige Überprüfung jeder einzelnen Ressource angewiesen sind, geraten dadurch schnell an ihre Grenzen. Erforderlich sind dynamisch skalierende Lösungen, die neue Workloads automatisch erkennen und anhand definierter Regeln schützen.
4. Anwendung und Control Plane müssen gemeinsam betrachtet werden
Eine Kubernetes-Anwendung besteht nicht ausschließlich aus ihren Containern und den darin verarbeiteten Daten. Ebenso relevant sind die Informationen der Steuerungsebene. Im verteilten Key-Value-Store etcd hält Kubernetes den gewünschten Clusterzustand vor. Dazu gehören Informationen über Deployments, ConfigMaps, Secrets, Custom Resource Definitions und Zugriffsregeln. Gehen diese Informationen verloren, kann die Wiederherstellung erheblich erschwert werden. Allerdings hängt der notwendige Sicherungsumfang auch vom Betriebsmodell ab. Unternehmen, die ihre Kubernetes-Konfiguration konsequent über GitOps verwalten, können zahlreiche Ressourcen aus der Versionsverwaltung rekonstruieren. In Umgebungen ohne durchgängige GitOps-Implementierung ist dagegen eine zusätzliche Sicherung des Clusterzustands besonders wichtig.
5. Die Wiederherstellung über Cluster- und Cloud-Grenzen hinweg
Die größte Herausforderung zeigt sich häufig erst beim Restore. Eine Backup-Plattform muss nicht nur die passende Sicherung identifizieren, sondern auch die Abhängigkeiten zwischen verschiedenen Anwendungskomponenten berücksichtigen. Dazu gehören Informationen über den ursprünglichen Cluster, den Namespace, den Sicherungszeitpunkt und den jeweiligen Anwendungskontext.
Zusätzliche Komplexität entsteht, wenn eine Anwendung in einer anderen Umgebung wiederhergestellt werden soll. Das Ziel kann ein anderer Kubernetes-Cluster, eine andere Cloud-Plattform oder eine Infrastruktur mit abweichender Kubernetes-Version sein.
Auch Unterschiede zwischen Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) und lokalen Kubernetes-Installationen müssen berücksichtigt werden. Eine leistungsfähige Backup-Lösung benötigt deshalb Mechanismen, um Konfigurationen und Ressourcen an die jeweilige Zielumgebung anzupassen.
Vier Komponenten einer vollständigen Kubernetes-Datensicherung
Nach Einschätzung von HYCU lässt sich eine umfassende Kubernetes-Backup-Strategie in vier zentrale Kategorien unterteilen. Die Unterschiede zwischen den am Markt verfügbaren Lösungen zeigen sich insbesondere darin, welche dieser Bereiche tatsächlich abgedeckt werden.
Persistent Volumes: Schutz der eigentlichen Anwendungsdaten
Persistent Volumes bilden die Grundlage für zustandsbehaftete Anwendungen. Dazu gehören beispielsweise Datenbanken, Message Queues und dateibasierte Speicherlösungen. Die Sicherung dieser Daten ist unverzichtbar. Viele Backup-Produkte konzentrieren sich allerdings vorwiegend auf diesen Bereich. Allein daraus ergibt sich noch keine vollständige Kubernetes-Sicherungsstrategie.
Namespace-Konfiguration: Wiederherstellung des Anwendungskontexts
Die zweite Kategorie umfasst die Konfiguration der jeweiligen Workload.
Dazu zählen YAML-Manifeste, ConfigMaps, Secrets, Service-Definitionen, Ingress-Regeln, NetworkPolicies und Custom Resources. Diese Informationen bestimmen, wie eine Anwendung innerhalb von Kubernetes bereitgestellt, verbunden und betrieben wird. Fehlen sie, können zwar einzelne Datenbestände wiederhergestellt werden. Die für ihren Betrieb notwendige Anwendungsumgebung muss jedoch möglicherweise manuell rekonstruiert werden.
Control Plane: Sicherung des Clusterzustands
Die dritte Kategorie betrifft die Kubernetes-Control-Plane und insbesondere die in etcd gespeicherten Informationen. Hierzu gehören der gewünschte Zustand der Workloads, rollenbasierte Zugriffskontrollen (RBAC), Custom Resource Definitions und registrierte Admission Webhooks. Wie umfangreich diese Informationen gesichert werden müssen, hängt von der vorhandenen Automatisierung ab.
Konsequent umgesetzte GitOps-Konzepte ermöglichen die Rekonstruktion vieler Konfigurationen aus versionierten Quellen. Wo diese Grundlage fehlt, muss die Backup-Strategie sicherstellen, dass die entsprechenden Informationen anderweitig verfügbar bleiben.
Anwendungskonsistenz: Abhängigkeiten zwischen Pods berücksichtigen
Die vierte Kategorie umfasst die Anwendung als zusammenhängende Einheit. Insbesondere verteilte Anwendungen bestehen häufig aus mehreren Pods, die auf gemeinsame Datenbestände zugreifen oder voneinander abhängig sind.
Eine Sicherung muss deshalb die relevanten Ressourcen koordiniert erfassen.
Bei transaktionsbasierten Anwendungen ist zusätzlich sicherzustellen, dass der wiederhergestellte Datenbestand konsistent ist. Eine Aneinanderreihung unabhängiger Snapshots reicht dafür nicht grundsätzlich aus.
Kubernetes-Labels ermöglichen eine automatisierte Backup-Steuerung. Eine zentrale Rolle bei der Automatisierung spielen Kubernetes-Labels und Metadaten. Sie ermöglichen es, Ressourcen anhand definierter Schlüssel-Wert-Paare zu kennzeichnen und logisch zusammenzufassen.
Backup-Plattformen können diese Informationen über die Kubernetes-API auswerten und daraus automatisierte Schutzmaßnahmen ableiten. So lässt sich beispielsweise festlegen, welche Anwendungen gesichert werden müssen, welche Richtlinien gelten und welche zusammengehörigen Ressourcen in einen gemeinsamen Sicherungsprozess einzubeziehen sind.
Neue Workloads können dadurch automatisch einer passenden Backup-Richtlinie zugeordnet werden. Werden Anwendungen stillgelegt, entfällt zugleich der Bedarf für weitere Sicherungsaufträge. Backup-Jobs können als Kubernetes-Workloads ausgeführt werden, deren Platzierung wiederum durch den kube-scheduler erfolgt.
Dieses Modell unterscheidet sich deutlich von klassischen Backup-Architekturen.
Dort müssen Administratoren häufig einzelne Systeme registrieren, Sicherungspläne erstellen und die Einhaltung der Richtlinien manuell überwachen. In einem Kubernetes-nativen Ansatz verschiebt sich der Schwerpunkt dagegen auf die Definition und Durchsetzung übergreifender Schutzrichtlinien. Die Backup-Plattform reagiert dynamisch auf Veränderungen innerhalb der Umgebung.
Drei typische Fehler bei der Kubernetes-Datensicherung
Trotz der wachsenden Bedeutung containerisierter Anwendungen bestehen nach Einschätzung von HYCU weiterhin erhebliche Unterschiede zwischen den verfügbaren Backup-Lösungen. Insbesondere drei Fehler können dazu führen, dass eine vermeintlich vollständige Sicherung im Ernstfall nicht den gewünschten Schutz bietet.
Fehler 1: Ausschließlich Persistent Volumes sichern
Die Sicherung persistenter Speicherbereiche gehört zu den grundlegenden Funktionen vieler Kubernetes-Backup-Produkte. Problematisch wird es, wenn diese Funktion bereits als vollständiger Anwendungsschutz betrachtet wird.
PV-Snapshots enthalten zwar die gespeicherten Daten, aber nicht zwangsläufig die dazugehörigen Namespace-Konfigurationen, Manifeste, Secrets oder Operator-Ressourcen. Im Wiederherstellungsfall stehen damit möglicherweise Daten zur Verfügung, ohne dass die zugehörige Anwendung unmittelbar wieder gestartet werden kann. Storage-only-Backups sind deshalb ein wichtiger Bestandteil, ersetzen jedoch keine ganzheitliche Kubernetes-Backup-Strategie.
Fehler 2: Klassische VM-Backup-Lösungen lediglich erweitern
Als Kubernetes zwischen 2019 und 2021 zunehmend in produktiven Unternehmensumgebungen eingesetzt wurde, ergänzten zahlreiche etablierte Backup-Anbieter ihre bestehenden Produkte um entsprechende Funktionen. Häufig erfolgte dies über zusätzliche Plug-ins und Schnittstellen zu Kubernetes-APIs. Solche Erweiterungen ermöglichen zwar grundsätzlich die Sicherung containerisierter Ressourcen. Sie übernehmen jedoch nicht automatisch das dynamische Betriebsmodell von Kubernetes. Wenn jede Workload weiterhin wie ein eigenständiges, dauerhaft verfügbares System behandelt wird, entstehen zusätzliche Verwaltungsaufwände und Datensicherungssilos. Entscheidend ist daher weniger die bloße Unterstützung von Kubernetes als vielmehr die Frage, wie tief eine Backup-Lösung in dessen Architektur und Automatisierungsmechanismen integriert ist.
Fehler 3: Die Control Plane bei der Wiederherstellung übersehen
Ein weiterer Fehler besteht darin, ausschließlich Anwendungsdaten und einzelne Konfigurationsdateien zu sichern, ohne den Clusterzustand ausreichend zu berücksichtigen. In vollständig automatisierten GitOps-Umgebungen lassen sich zahlreiche Ressourcen aus versionierten Konfigurationen erneut bereitstellen. In der Praxis existieren jedoch häufig Mischformen. Dazu gehören manuell angewandte Konfigurationen, über kubectl installierte Operatoren, nicht versionierte Custom Resource Definitions und Secrets, die bewusst außerhalb der Versionsverwaltung gespeichert werden.
Geht der etcd-Zustand verloren, fehlen unter Umständen wichtige Informationen über die zuvor bereitgestellte Infrastruktur. Unternehmen benötigen deshalb entweder eine verlässlich getestete Möglichkeit zur Rekonstruktion der Control Plane oder eine geeignete Sicherung der dafür erforderlichen Informationen.
Wiederherstellung testen: Warum eine Tabletop-Übung sinnvoll ist
Ob eine Kubernetes-Backup-Strategie tatsächlich funktioniert, zeigt sich nicht allein an erfolgreich abgeschlossenen Sicherungsaufträgen. Entscheidend ist, ob sich eine geschäftskritische Anwendung nach einem schwerwiegenden Ausfall vollständig und innerhalb der erforderlichen Zeit wiederherstellen lässt. HYCU empfiehlt deshalb eine Tabletop-Übung.
Dazu wählen Unternehmen eine besonders wichtige containerisierte Anwendung aus und simulieren deren Wiederherstellung in einem anderen Cluster und einer anderen Region. Die ursprüngliche Kubernetes-Umgebung gilt dabei als vollständig ausgefallen und steht für die Wiederherstellung nicht mehr zur Verfügung. Im Mittelpunkt stehen Fragen nach den vorhandenen Sicherungsdaten, benötigten Konfigurationen, technischen Abhängigkeiten und erforderlichen manuellen Eingriffen. Insbesondere dort, wo Administratoren während der Wiederherstellung auf nicht dokumentierte Informationen oder umfangreiche Handarbeit angewiesen sind, besteht Optimierungsbedarf.
Fazit: Ein erfolgreiches Kubernetes-Backup ist noch keine erfolgreiche Wiederherstellung
Kubernetes verändert nicht nur die Bereitstellung und Skalierung von Anwendungen, sondern auch die Anforderungen an deren Absicherung. Wer weiterhin ausschließlich virtuelle Maschinen oder persistente Speicherbereiche schützt, riskiert im Ernstfall unvollständige Wiederherstellungen.
Eine belastbare Backup-Strategie muss deshalb Anwendungsdaten, Konfigurationen, Clusterzustand und Abhängigkeiten gemeinsam betrachten. Der eigentliche Maßstab ist dabei nicht die Anzahl erfolgreich abgeschlossener Backups, sondern die Fähigkeit, eine vollständige Anwendung nach einem Ausfall zuverlässig wieder in Betrieb zu nehmen. Die Bearbeitung basiert auf dem bereitgestellten HYCU-Fachbeitrag und übernimmt dessen zentrale technische Aussagen und Argumentationsstruktur.
