Kubernetes Backup und Restore mit Velero – Anwendungen und Persistent Volumes sichern

Wer einen Kubernetes-Cluster betreibt, beschäftigt sich meistens zuerst mit Deployments, Services, Pods und der automatischen Skalierung von Anwendungen. Schließlich bietet Kubernetes zahlreiche Mechanismen, um ausgefallene Container zu ersetzen und Anwendungen auf unterschiedlichen Nodes bereitzustellen. Doch was passiert eigentlich, wenn nicht nur ein einzelner Pod ausfällt, sondern wichtige Kubernetes-Ressourcen oder sogar komplette Anwendungsdaten verloren gehen?

Genau hier wird das Thema Kubernetes Backup und Restore interessant. Denn obwohl Kubernetes viele Aufgaben rund um die Verfügbarkeit automatisiert, besitzt es nicht automatisch eine vollständige Backup-Lösung für sämtliche Anwendungen und ihre Daten.

Ein Deployment kann beispielsweise einen ausgefallenen Pod ersetzen. Wenn allerdings ein Persistent Volume beschädigt wird oder eine wichtige Konfiguration versehentlich gelöscht wurde, hilft dieser Mechanismus alleine nicht weiter. Schließlich kann Kubernetes nur versuchen, den gewünschten Zustand auf Grundlage der noch vorhandenen Informationen wiederherzustellen.

Deshalb gehört eine durchdachte Backup-Strategie zu jeder produktiven Kubernetes-Umgebung. Eine interessante Lösung dafür ist Velero. Das Open-Source-Projekt ermöglicht die Sicherung und Wiederherstellung von Kubernetes-Ressourcen und unterstützt verschiedene Verfahren zur Sicherung persistenter Daten.

In diesem Artikel schauen wir uns genauer an, wie Kubernetes Backup und Restore mit Velero funktioniert, welche Komponenten benötigt werden und worauf du beim Einsatz von Persistent Volumes achten solltest. Außerdem beschäftigen wir uns mit automatisierten Sicherungen, typischen Wiederherstellungsszenarien und der Frage, warum ein etcd-Snapshot alleine häufig nicht ausreicht.

Warum benötigt Kubernetes überhaupt eine Backup-Lösung?

Auf den ersten Blick könnte man meinen, dass Kubernetes bereits genügend Mechanismen für die Wiederherstellung bereitstellt. Schließlich überwachen verschiedene Controller den Clusterzustand und versuchen kontinuierlich, Abweichungen vom gewünschten Zustand zu korrigieren.

Wenn beispielsweise ein Pod ausfällt, erstellt der zuständige Controller unter geeigneten Voraussetzungen eine neue Instanz. Auch beim Ausfall eines Worker Nodes können Workloads auf andere verfügbare Nodes verteilt werden, sofern die benötigten Ressourcen und Speicherzugriffe vorhanden sind.

Allerdings handelt es sich dabei um Mechanismen zur Aufrechterhaltung des Betriebs und nicht um eine klassische Datensicherung.

Stell dir vor, ein Administrator löscht versehentlich einen produktiven Namespace. Damit können Deployments, Services, ConfigMaps, Secrets und weitere Ressourcen verschwinden. Da die Objekte nun nicht mehr im gewünschten Zustand vorhanden sind, wird Kubernetes sie nicht automatisch aus einer früheren Version wiederherstellen.

Ähnlich sieht es bei Persistent Volumes aus. Wenn eine Anwendung wichtige Daten dauerhaft speichert, müssen diese Daten unabhängig vom Lebenszyklus ihrer Pods geschützt werden.

Ein PersistentVolumeClaim sorgt zwar dafür, dass ein Pod geeigneten Speicher verwenden kann. Allerdings bedeutet das nicht, dass die darauf gespeicherten Informationen gegen versehentliche Löschungen, beschädigte Dateisysteme oder Storage-Ausfälle abgesichert sind.

Genau deshalb muss zwischen Hochverfügbarkeit und Datensicherung unterschieden werden.

Hochverfügbarkeit sorgt dafür, dass Anwendungen trotz bestimmter Fehler weiterlaufen können. Ein Backup ermöglicht dagegen die Wiederherstellung eines früheren Daten- oder Konfigurationsstands.

Was ist Velero?

Velero ist ein Open-Source-Werkzeug zur Sicherung, Wiederherstellung und Migration von Kubernetes-Ressourcen sowie unterstützten persistenten Volumes.

Ursprünglich wurde das Projekt unter dem Namen Heptio Ark bekannt. Heute wird Velero als eigenständiges Open-Source-Projekt weiterentwickelt und in unterschiedlichen Kubernetes-Umgebungen eingesetzt.

Ein wichtiger Vorteil besteht darin, dass Velero direkt mit der Kubernetes-API zusammenarbeitet. Dadurch lassen sich beispielsweise Deployments, Services, ConfigMaps, Secrets und weitere API-Ressourcen sichern.

Außerdem kann Velero abhängig von der Storage-Infrastruktur persistente Daten berücksichtigen. Dafür stehen verschiedene Verfahren zur Verfügung, darunter CSI Volume Snapshots und dateibasierte Sicherungen.

Die Sicherungen werden normalerweise in einem geeigneten Objektspeicher abgelegt. Häufig kommen dafür Amazon S3, kompatible S3-Storage-Systeme oder andere unterstützte Cloud-Storage-Angebote zum Einsatz.

Das ist besonders interessant, wenn Backups unabhängig vom eigentlichen Kubernetes-Cluster gespeichert werden sollen.

Allerdings sollte man Velero nicht als universelle Lösung betrachten, die automatisch sämtliche Daten jeder beliebigen Anwendung konsistent sichert. Gerade bei Datenbanken müssen zusätzliche Anforderungen berücksichtigt werden.

Wie funktioniert die Architektur von Velero?

Um Velero sinnvoll einsetzen zu können, lohnt sich ein Blick auf die beteiligten Komponenten.

Velero besteht im Wesentlichen aus einer Kommandozeilenanwendung und serverseitigen Komponenten, die innerhalb des Kubernetes-Clusters betrieben werden.

Die Velero CLI verwendest du beispielsweise, um Backups zu erstellen, bestehende Sicherungen anzuzeigen oder Wiederherstellungen anzustoßen.

Die eigentliche Verarbeitung erfolgt über die Velero-Controller im Cluster. Diese reagieren auf entsprechende Kubernetes-Ressourcen und übernehmen die Koordination der Backup- und Restore-Vorgänge.

Für die Speicherung werden sogenannte BackupStorageLocations konfiguriert. Diese beschreiben, wo Velero seine Backup-Metadaten und weitere Sicherungsdaten ablegen soll.

Abhängig vom gewählten Verfahren werden außerdem Storage-Plugins, CSI-Treiber oder der Velero Node Agent benötigt.

Der Node Agent ist insbesondere für dateibasierte Volume-Backups und bestimmte Datenbewegungsverfahren wichtig.

Dadurch entsteht eine Architektur, in der Kubernetes-Ressourcen über die API erfasst werden, während persistente Daten über das jeweils passende Storage-Verfahren gesichert werden.

Welche Daten kann Velero sichern?

Bei einem Kubernetes Backup mit Velero müssen grundsätzlich zwei Arten von Informationen unterschieden werden.

Die erste Kategorie umfasst Kubernetes-Ressourcen. Dazu gehören beispielsweise Deployments, StatefulSets, Services, ConfigMaps, Secrets und verschiedene andere Kubernetes-Objekte.

Diese Ressourcen beschreiben, wie eine Anwendung innerhalb des Clusters bereitgestellt und verwaltet wird.

Die zweite Kategorie umfasst die eigentlichen Anwendungsdaten. Das können beispielsweise Dateien auf einem Persistent Volume, hochgeladene Dokumente oder Datenbankdateien sein.

Während Kubernetes-Ressourcen über die API gesichert werden können, benötigen persistente Daten ein zusätzliches Sicherungsverfahren.

Velero unterstützt dafür unterschiedliche Methoden, die allerdings von der verwendeten Storage-Infrastruktur abhängen.

Besonders wichtig ist deshalb die Unterscheidung zwischen CSI Snapshots, CSI Snapshot Data Movement und File System Backup.

Persistent Volumes mit CSI Snapshots sichern

Viele moderne Kubernetes-Storage-Lösungen verwenden das Container Storage Interface, kurz CSI. Darüber können Storage-Systeme in Kubernetes integriert werden, ohne dass jede Storage-Lösung direkt Bestandteil des Kubernetes-Kerns sein muss.

Unterstützt der verwendete CSI-Treiber die Erstellung von Volume Snapshots, kann Velero diese Funktion zur Sicherung persistenter Daten verwenden.

Der Vorteil liegt darin, dass der Snapshot auf Ebene des Storage-Systems erstellt wird. Dadurch muss Velero nicht sämtliche Dateien einzeln aus einem laufenden Pod auslesen.

Allerdings bedeutet ein Storage-Snapshot nicht automatisch, dass die Daten auf ein unabhängiges Backup-System übertragen wurden.

Bei bestimmten Konfigurationen verbleiben Snapshots zunächst auf derselben Storage-Infrastruktur. Wird diese vollständig beschädigt oder gelöscht, können auch die Snapshots betroffen sein.

Deshalb ist es wichtig, zwischen einem lokal gespeicherten Snapshot und einer unabhängigen Datensicherung zu unterscheiden.

Außerdem muss der CSI-Treiber die erforderlichen Snapshot-Funktionen unterstützen. Je nach Kubernetes-Installation werden dafür passende VolumeSnapshotClasses und die zugehörigen Snapshot-Komponenten benötigt.

CSI Snapshot Data Movement – Daten unabhängig sichern

Eine interessante Erweiterung ist das sogenannte CSI Snapshot Data Movement.

Bei diesem Verfahren erstellt Velero zunächst einen Snapshot über den CSI-Treiber. Anschließend werden die gesicherten Daten mithilfe eines Data Movers in einen konfigurierten Backup-Speicher übertragen.

Dadurch kann eine zusätzliche Trennung zwischen dem produktiven Storage-System und dem eigentlichen Backup-Ziel erreicht werden.

Gerade in On-Premises-Umgebungen ist das interessant, weil ein Snapshot auf demselben Storage-System nicht alle Disaster-Recovery-Anforderungen erfüllen kann.

Allerdings benötigt auch dieses Verfahren eine passende CSI- und Data-Mover-Konfiguration.

Je nach eingesetzter Velero-Version und Storage-Funktionalität stehen unterschiedliche Datenbewegungsverfahren zur Verfügung.

Deshalb solltest du vor der Einführung immer prüfen, ob dein CSI-Treiber die benötigten Funktionen unterstützt und ob der gewählte Datenbewegungsmechanismus mit deiner Infrastruktur kompatibel ist.

File System Backup mit Velero

Nicht jede Storage-Lösung unterstützt CSI Snapshots. Besonders bei bestimmten lokalen oder dateibasierten Storage-Systemen kann das zum Problem werden.

Für solche Situationen bietet Velero das File System Backup, häufig auch als FSB bezeichnet.

Dabei werden Dateien aus eingebundenen Pod-Volumes gelesen und über den Velero Node Agent in einem Backup-Speicher gesichert.

Für die Datenübertragung und Speicherung verwendet Velero in aktuellen Versionen entsprechende Kopia-Funktionen.

Ein Vorteil ist die vergleichsweise hohe Flexibilität. Das Verfahren kann auch bei verschiedenen Volume-Typen eingesetzt werden, für die keine geeignete native Snapshot-Funktion zur Verfügung steht.

Allerdings gibt es wichtige Einschränkungen. Beispielsweise werden Dateien aus einem laufenden Dateisystem gelesen, während die Anwendung möglicherweise weiterhin Änderungen daran vornimmt.

Dadurch kann eine Sicherung entstehen, bei der nicht sämtliche Dateien denselben logischen Zeitpunkt repräsentieren.

Gerade bei Datenbanken ist das problematisch. Eine einfache Kopie des laufenden Datenverzeichnisses stellt nicht automatisch ein konsistentes Datenbank-Backup dar.

Deshalb sollten produktive Datenbanken mit geeigneten anwendungsspezifischen Sicherungsmechanismen oder entsprechend abgestimmten Snapshot-Verfahren geschützt werden.

Velero in Kubernetes installieren

Für die Installation benötigst du zunächst einen funktionsfähigen Kubernetes-Cluster und eine entsprechend konfigurierte kubectl-Verbindung.

Außerdem muss ein geeignetes Backup-Ziel vorhanden sein. Häufig wird dafür ein S3-kompatibler Objektspeicher verwendet.

Zusätzlich benötigst du die Velero CLI auf deinem Administrationsrechner.

Die aktuelle CLI und die jeweils unterstützten Kubernetes-Versionen findest du auf der offiziellen Velero-Projektseite.

Bevor du die Installation startest, solltest du außerdem festlegen, welches Storage-Plugin verwendet wird und wie die Authentifizierung am Backup-Speicher erfolgt.

Beispiel einer Velero-Installation

Das folgende Beispiel zeigt den grundsätzlichen Aufbau eines Installationsbefehls für einen S3-basierten Backup-Speicher.

Die Platzhalter müssen an deine Umgebung angepasst werden. Insbesondere muss die Plugin-Version zur installierten Velero-Version passen.

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:<PLUGIN_VERSION> \
  --bucket <BACKUP_BUCKET> \
  --secret-file <CREDENTIALS_FILE> \
  --backup-location-config region=<REGION> \
  --use-node-agent

Der Parameter --provider aws wird in diesem Beispiel zusammen mit dem AWS-Plugin verwendet. Dieses kann je nach Konfiguration auch mit bestimmten S3-kompatiblen Storage-Systemen eingesetzt werden.

Für alternative S3-Endpunkte können zusätzliche Konfigurationsparameter erforderlich sein.

Mit --bucket wird der verwendete Backup-Bucket angegeben, während --secret-file auf eine lokale Datei mit den benötigten Zugangsdaten verweist.

Der Parameter --use-node-agent aktiviert die Komponenten, die für File System Backups benötigt werden.

Allerdings sollte dieser Parameter nur dann eingesetzt werden, wenn die entsprechende Funktion tatsächlich benötigt wird. In bestimmten Umgebungen müssen zusätzliche Sicherheits- und Berechtigungseinstellungen berücksichtigt werden.

Nach der Installation kannst du den Zustand der Velero-Komponenten überprüfen:

kubectl get pods -n velero

Außerdem lohnt sich ein Blick auf die konfigurierte BackupStorageLocation:

velero backup-location get

Erst wenn das Backup-Ziel korrekt erreichbar ist, solltest du mit den ersten Sicherungstests beginnen.

Praxisbeispiel: Einen Kubernetes Namespace sichern

Schauen wir uns an, wie ein einfaches Backup erstellt wird.

Angenommen, du betreibst eine Testanwendung innerhalb eines Namespaces mit dem Namen demo-app.

Dieser Namespace enthält beispielsweise ein Deployment, einen Service und eine ConfigMap.

Um die Kubernetes-Ressourcen dieses Namespaces zu sichern, kannst du folgenden Befehl verwenden:

velero backup create demo-app-backup \
  --include-namespaces demo-app

Velero erstellt daraufhin ein Backup und speichert die entsprechenden Informationen im konfigurierten Backup-Speicher.

Welche Volume-Daten zusätzlich enthalten sind, hängt von der verwendeten Backup- und Storage-Konfiguration ab.

Deshalb solltest du nicht automatisch davon ausgehen, dass jeder PersistentVolumeClaim vollständig gesichert wurde.

Backup-Status überprüfen

Mit folgendem Befehl kannst du dir die vorhandenen Backups anzeigen lassen:

velero backup get

Weitere Informationen erhältst du über:

velero backup describe demo-app-backup --details

Zusätzlich kannst du die Backup-Logs untersuchen:

velero backup logs demo-app-backup

Gerade bei Persistent Volumes lohnt sich die detaillierte Prüfung. Dort sollte nachvollziehbar sein, ob Volume Snapshots, File System Backups oder andere konfigurierte Sicherungsverfahren verwendet wurden.

Ein Backup mit dem Status Completed sollte deshalb nicht die einzige Grundlage für die Bewertung der Datensicherung sein.

Persistent Volumes mit File System Backup sichern

Wenn du für eine Testumgebung ausdrücklich das dateibasierte Backup-Verfahren verwenden möchtest, kannst du bei entsprechend vorbereiteter Velero-Installation folgenden Befehl einsetzen:

velero backup create demo-app-fs-backup \
  --include-namespaces demo-app \
  --default-volumes-to-fs-backup

Mit --default-volumes-to-fs-backup weist du Velero an, geeignete Pod-Volumes standardmäßig über das File System Backup zu berücksichtigen.

Allerdings werden nicht automatisch sämtliche denkbaren Volume-Typen unterstützt. Beispielsweise sind direkte hostPath-Volumes für dieses Verfahren nicht geeignet.

Außerdem muss der Velero Node Agent korrekt eingerichtet sein.

Ob tatsächlich Volume-Daten gesichert wurden, lässt sich unter anderem über die entsprechenden PodVolumeBackup-Ressourcen nachvollziehen.

kubectl get podvolumebackups -n velero

Bei der Auswertung solltest du besonders auf fehlgeschlagene Sicherungen und nicht unterstützte Volumes achten.

Kubernetes Ressourcen mit Velero wiederherstellen

Ein Backup ist natürlich nur dann sinnvoll, wenn sich die gespeicherten Informationen auch wiederherstellen lassen.

Velero bietet dafür den Befehl velero restore create.

Für unser zuvor erstelltes Test-Backup könnte die Wiederherstellung folgendermaßen gestartet werden:

velero restore create demo-app-restore \
  --from-backup demo-app-backup

Velero verarbeitet anschließend die im Backup enthaltenen Ressourcen und versucht, sie innerhalb des Kubernetes-Clusters wiederherzustellen.

Allerdings musst du dabei beachten, dass bereits vorhandene Ressourcen zu Konflikten führen können.

Velero überschreibt nicht grundsätzlich alle vorhandenen Objekte. Das genaue Verhalten hängt von den Ressourcentypen, der Restore-Konfiguration und der verwendeten Version ab.

Deshalb würde ich eine Wiederherstellung zunächst in einer isolierten Testumgebung durchführen, statt unmittelbar in einen produktiven Namespace einzugreifen.

Restore-Status kontrollieren

Den Fortschritt kannst du mit folgendem Befehl überprüfen:

velero restore get

Weitere Informationen liefert:

velero restore describe demo-app-restore --details

Auch die Restore-Logs sind wichtig:

velero restore logs demo-app-restore

Nach Abschluss solltest du zusätzlich die Kubernetes-Ressourcen überprüfen:

kubectl get all -n demo-app

Dieser Befehl zeigt allerdings nicht sämtliche Ressourcentypen an. Deshalb solltest du bei Bedarf auch ConfigMaps, Secrets, PersistentVolumeClaims und weitere für die Anwendung relevante Objekte kontrollieren.

Entscheidend ist letztlich, ob die Anwendung nach der Wiederherstellung tatsächlich wieder korrekt funktioniert.

Automatische Kubernetes Backups mit Velero erstellen

Manuelle Backups sind für Tests hilfreich. In produktiven Umgebungen solltest du Sicherungen allerdings automatisieren.

Velero bietet dafür sogenannte Schedules.

Diese verwenden eine zeitbasierte Konfiguration, mit der regelmäßig neue Backup-Vorgänge erstellt werden.

Ein tägliches Backup könnte beispielsweise so eingerichtet werden:

velero schedule create daily-backup \
  --schedule="0 2 * * *" \
  --include-namespaces demo-app \
  --ttl 168h

In diesem Beispiel wird täglich um 02:00 Uhr gemäß der vom Schedule verwendeten Zeitzonen-Konfiguration eine Sicherung angestoßen.

Mit --ttl 168h wird eine Aufbewahrungsdauer von sieben Tagen festgelegt.

Allerdings solltest du die Backup-Frequenz und Aufbewahrungsdauer nicht einfach aus einem Tutorial übernehmen.

Stattdessen sollten diese Werte zu den Anforderungen deiner Anwendungen passen.

Wenn sich beispielsweise geschäftskritische Daten ständig verändern, kann eine tägliche Sicherung zu selten sein.

Außerdem sollten Backups nicht nur regelmäßig ausgeführt, sondern auch überwacht werden.

Ein geplanter Backup-Job, der seit mehreren Wochen fehlschlägt, bietet schließlich keinen zuverlässigen Schutz.

Warum Velero kein Ersatz für etcd-Backups ist

Wenn du bereits mit der Wiederherstellung von etcd gearbeitet hast, stellt sich möglicherweise die Frage, ob Velero einen etcd-Snapshot ersetzen kann.

Die Antwort lautet: Nicht vollständig.

etcd speichert den Zustand des Kubernetes-Clusters. Ein etcd-Snapshot ermöglicht es, den Datenbestand dieser zentralen Datenbank zu sichern und unter geeigneten Voraussetzungen wiederherzustellen.

Velero verfolgt dagegen einen stärker anwendungs- und ressourcenorientierten Ansatz.

Es sichert Kubernetes-Ressourcen über die API und kann darüber hinaus persistente Anwendungsdaten berücksichtigen.

Beide Verfahren erfüllen also unterschiedliche Aufgaben.

Ein etcd-Snapshot kann beispielsweise bei einem schwerwiegenden Ausfall der Control Plane hilfreich sein.

Ein Velero-Backup eignet sich dagegen besonders dann, wenn bestimmte Anwendungen, Namespaces oder Ressourcen wiederhergestellt oder in andere Umgebungen übertragen werden sollen.

Für eine umfassende Disaster-Recovery-Strategie kann deshalb die Kombination beider Verfahren sinnvoll sein.

Wichtig ist außerdem, dass ein Velero-Backup ohne funktionsfähige Kubernetes-API nicht einfach auf dieselbe Weise wiederhergestellt werden kann. Zunächst muss eine geeignete Kubernetes-Zielumgebung verfügbar sein.

Besonderheiten bei Datenbanken in Kubernetes

Bei Datenbanken solltest du besonders vorsichtig sein, wenn du ein Backup-Verfahren auswählst.

PostgreSQL, MySQL und andere Datenbanksysteme schreiben während des Betriebs kontinuierlich Informationen auf ihre Datenträger.

Eine dateibasierte Sicherung kann deshalb Dateien erfassen, die sich während des Backup-Vorgangs verändern.

Das kann zu inkonsistenten Datenbeständen führen.

Auch ein Storage-Snapshot bietet nicht automatisch sämtliche Garantien einer anwendungskonsistenten Sicherung.

Deshalb sollte das Backup-Verfahren zur jeweiligen Datenbank passen.

Für PostgreSQL können beispielsweise logische Sicherungen, physische Backups oder geeignete Verfahren auf Grundlage von Write-Ahead-Logs eingesetzt werden.

Bei MySQL stehen ebenfalls datenbankspezifische Backup-Mechanismen zur Verfügung.

Darüber hinaus bieten manche Kubernetes-Datenbank-Operatoren integrierte Backup- und Wiederherstellungsfunktionen.

Gerade bei geschäftskritischen Datenbanken würde ich deshalb prüfen, ob Velero für die Kubernetes-Ressourcen verwendet wird, während die eigentlichen Daten zusätzlich über ein datenbankspezifisches Verfahren gesichert werden.

Das mag zunächst mehr Aufwand bedeuten, kann aber die Zuverlässigkeit der Wiederherstellung erheblich verbessern.

Was passiert bei einem vollständigen Cluster-Ausfall?

Ein besonders interessantes Szenario ist der vollständige Verlust eines Kubernetes-Clusters.

In diesem Fall reicht es nicht aus, einfach den Velero-Restore-Befehl auszuführen. Schließlich wird dafür zunächst eine funktionierende Kubernetes-Umgebung benötigt.

Deshalb muss im Rahmen einer vollständigen Disaster-Recovery-Strategie festgelegt werden, wie ein neuer Cluster bereitgestellt werden kann.

Dazu gehören beispielsweise die Netzwerkumgebung, benötigte StorageClasses, CSI-Treiber und weitere Infrastrukturkomponenten.

Erst wenn eine geeignete Zielumgebung vorhanden ist und Velero Zugriff auf den ursprünglichen Backup-Speicher besitzt, kann die Wiederherstellung der gesicherten Ressourcen beginnen.

Außerdem müssen mögliche Unterschiede zwischen altem und neuem Cluster berücksichtigt werden.

Beispielsweise können bestimmte StorageClasses, LoadBalancer-Konfigurationen oder externe Abhängigkeiten in der neuen Umgebung anders aussehen.

Deshalb sollte ein vollständiger Wiederherstellungstest nicht nur darin bestehen, einzelne Pods wieder sichtbar zu machen.

Vielmehr muss geprüft werden, ob die gesamte Anwendung einschließlich Netzwerk, Storage und externer Abhängigkeiten wieder funktioniert.

Typische Fehler bei Kubernetes Backup und Restore

Eine häufige Fehlerquelle ist die Annahme, dass ein erfolgreiches Velero-Backup automatisch sämtliche Anwendungsdaten enthält.

Wenn Volume-Backups nicht korrekt konfiguriert sind, können möglicherweise nur die Kubernetes-Ressourcen gesichert worden sein.

Ein weiterer Fehler ist die ausschließliche Speicherung der Backups innerhalb derselben Infrastruktur.

Fällt das gesamte Storage-System aus, können dadurch sowohl die produktiven Daten als auch die Backups betroffen sein.

Auch fehlende Berechtigungen für den Objektspeicher oder falsch konfigurierte Storage-Plugins führen häufig zu Problemen.

Besonders kritisch wird es außerdem, wenn Restore-Verfahren niemals getestet werden.

Schließlich können veraltete StorageClasses, nicht verfügbare Container-Images oder fehlende Cluster-Komponenten dazu führen, dass eine Wiederherstellung zwar teilweise funktioniert, die Anwendung aber trotzdem nicht startet.

Deshalb würde ich Backup- und Restore-Prozesse immer gemeinsam betrachten.

Wie sieht eine sinnvolle Backup-Strategie für Kubernetes aus?

Für eine produktive Kubernetes-Umgebung würde ich zunächst festlegen, welche Anwendungen und Ressourcen tatsächlich geschützt werden müssen.

Darauf aufbauend sollte entschieden werden, welches Backup-Verfahren für die jeweiligen Daten geeignet ist.

Eine mögliche Strategie könnte beispielsweise folgende Maßnahmen umfassen:

• Regelmäßige Velero-Backups wichtiger Kubernetes-Ressourcen.
• Geeignete Sicherungen der Persistent Volumes.
• Zusätzliche anwendungskonsistente Backups für Datenbanken.
• Unabhängige etcd-Snapshots für die Control Plane.
• Geschützte Speicherung der Backups außerhalb des produktiven Clusters.
• Automatische Überwachung der Backup-Jobs.
• Regelmäßige Wiederherstellungstests.
• Dokumentierte Recovery-Prozesse für verschiedene Ausfallszenarien.

Außerdem sollten Recovery Point Objective und Recovery Time Objective berücksichtigt werden.

Das Recovery Point Objective beschreibt, wie viel Datenverlust im Fehlerfall maximal akzeptabel ist.

Das Recovery Time Objective definiert dagegen, wie schnell eine Anwendung oder Infrastruktur wiederhergestellt werden soll.

Gerade bei größeren Kubernetes-Umgebungen helfen diese Anforderungen dabei, sinnvolle Backup-Intervalle und Wiederherstellungsverfahren festzulegen.

Häufig gestellte Fragen zu Kubernetes Backup und Restore

Was ist Velero in Kubernetes?

Velero ist ein Open-Source-Werkzeug zur Sicherung, Wiederherstellung und Migration von Kubernetes-Ressourcen. Zusätzlich unterstützt es verschiedene Verfahren zur Sicherung persistenter Anwendungsdaten, beispielsweise CSI Snapshots und File System Backups.

Kann Velero Persistent Volumes sichern?

Ja. Velero unterstützt unterschiedliche Verfahren zur Sicherung von Volume-Daten. Welche Methode verwendet werden kann, hängt vom Storage-System, dem CSI-Treiber und der Velero-Konfiguration ab.

Ist Velero ein Ersatz für etcd-Backups?

Nein. Velero und etcd-Snapshots erfüllen unterschiedliche Aufgaben. Während etcd-Snapshots den Zustand der zentralen Kubernetes-Datenbank sichern, ermöglicht Velero die Sicherung und Wiederherstellung von Kubernetes-Ressourcen und unterstützten persistenten Daten.

Kann ich mit Velero einen kompletten Kubernetes-Cluster wiederherstellen?

Velero kann viele gesicherte Kubernetes-Ressourcen und unterstützte Volume-Daten in einer geeigneten Zielumgebung wiederherstellen. Es ersetzt jedoch nicht automatisch die Bereitstellung der gesamten Cluster-Infrastruktur einschließlich Control Plane, Netzwerk und Storage-Systemen.

Wie kann ich automatische Kubernetes Backups erstellen?

Mit Velero Schedules lassen sich regelmäßige Sicherungen konfigurieren. Dabei wird über einen Zeitplan festgelegt, wann neue Backups erstellt werden sollen. Die Ausführung und der Erfolg dieser Backups sollten zusätzlich überwacht werden.

Kann Velero Datenbanken sichern?

Velero kann Kubernetes-Ressourcen und geeignete persistente Volumes sichern, die von Datenbanken verwendet werden. Allerdings ist nicht jedes Volume-Backup automatisch anwendungskonsistent. Für produktive Datenbanken sollten deshalb geeignete datenbankspezifische Backup-Verfahren berücksichtigt werden.

Fazit: Kubernetes Backup und Restore gehört zum produktiven Clusterbetrieb

Kubernetes bietet zahlreiche Mechanismen, um Anwendungen automatisiert bereitzustellen und ausgefallene Pods zu ersetzen. Allerdings bedeutet diese Selbstheilung nicht, dass wichtige Daten und Konfigurationen automatisch gegen Verlust geschützt sind.

Genau deshalb ist eine durchdachte Backup-Strategie für produktive Kubernetes-Umgebungen unverzichtbar.

Velero bietet dafür interessante Möglichkeiten, weil Kubernetes-Ressourcen direkt über die API gesichert und unterschiedliche Verfahren für persistente Daten integriert werden können.

Besonders wichtig finde ich dabei die Trennung zwischen Kubernetes-Konfigurationen, Persistent Volumes und eigentlichen Anwendungsdaten.

Ein erfolgreich gesichertes Deployment hilft schließlich nur begrenzt, wenn die zugehörige Datenbank nicht mehr wiederhergestellt werden kann.

Außerdem sollte ein Backup nicht ausschließlich anhand seines Status bewertet werden. Erst durch regelmäßige Wiederherstellungstests lässt sich feststellen, ob die gespeicherten Informationen im Ernstfall tatsächlich verwendet werden können.

Mein Tipp wäre deshalb, mit einer kleinen Testanwendung zu beginnen. Erstelle einen eigenen Namespace, sichere ihn mit Velero und stelle ihn anschließend in einer isolierten Testumgebung wieder her.

Wenn dieser Ablauf funktioniert, kannst du schrittweise Persistent Volumes, Datenbank-Backups und komplexere Anwendungen berücksichtigen.

Darüber hinaus würde ich die Wiederherstellung eines vollständigen Clusters zumindest in einer Testumgebung durchspielen. Gerade dort zeigen sich häufig Abhängigkeiten, die während des normalen Betriebs kaum auffallen.

Mein Fazit: Ein Kubernetes-Backup ist erst dann wirklich wertvoll, wenn du auch weißt, wie du Anwendungen und ihre Daten zuverlässig wiederherstellen kannst.

Velero kann dabei ein wichtiger Bestandteil deiner Backup-Strategie sein. Entscheidend ist jedoch, dass die gewählten Sicherungsverfahren zu deiner Storage-Infrastruktur und den Anforderungen deiner Anwendungen passen.

Weiterführende Informationen

Die offizielle Velero-Dokumentation bietet ausführliche Informationen zur Installation, Konfiguration und Wiederherstellung von Kubernetes-Ressourcen.

Weitere Details zum dateibasierten Volume-Backup findest du in der Velero-Dokumentation zum File System Backup.

Für die Sicherung von Persistent Volumes über CSI ist außerdem die Dokumentation zum CSI Snapshot Data Movement interessant.