Veeams "Backup & Replication" zählt zu den populärsten Sicherungsanwendungen für vSphere-Umgebungen. Allerdings verliert diese Virtualisierungsplattform zunehmend an Bedeutung, insbesondere bei kleinen und mittelständischen Unternehmen. Dies hat sowohl mit den Anpassungen des Lizenzmodells nach der Übernahme durch Broadcom zu tun als auch mit der zunehmenden Adoption von Kubernetes als Applikationsplattform. Und bei Letzterem greifen IT-Verantwortliche lokal eher auf Red Hat, SUSE oder Open-Source-Projekte zurück als auf VMware. Und entsprechende Dienste in der Cloud liefern Amazon, Google und Microsoft ebenso wie regionale Anbieter à la Telekom oder Ionos.

In seiner ursprünglichen Form setzte Kubernetes noch überhaupt keine persistenten Daten ein. Die Idee der Container-Plattform war, die Informationen redun- dant auf viele Container und Knoten ohne jegliche persistente Speicherung zu verteilen. Hier sollte die Applikation selbst von Zeit zu Zeit Teile ihrer Inhalte auf einen Objektspeicher zur Sicherung auslagern. Doch das "stateless"-Konzept konnte sich nicht durchsetzen. Die Anwender hätten nicht nur viel Zeit und Geld in die Restrukturierung des Applikationscodes investieren müssen, auch die komplette Datenhaltung und -verwaltung verlangt andere Konzepte.

Leider hängen wir — seit mittlerweile 46 Jahren — an tabellarischen Datenbanken mit SQL-Abfragen, obwohl es in der Zwischenzeit viele bessere Methoden gibt, Daten schneller und vor allem sicherer verteilt in Clustern zu lagern. Daher wimmelt es auch in Kubernetes-Clustern nur so von PVs (Persistent Volumes) und Datenbank-PODs, die ihre wertvollen Informationen dort lagern müssen. Daher benötigt Kubernetes dann doch wieder Backuptools – die ihre Aufgaben allerdings ein bisschen anders angehen müssen, als das noch bei klassischen virtuellen Maschinen der Fall war.

Im Jahr 2017 gründeten zwei Softwareingenieure das Unternehmen "Kasten", das das Kubernetes-Backuptool "K10" entwickelte. Die meisten Sicherungsprogramme konzentrieren sich darauf, die Datenbestände einer Anwendung, aber nicht die Konfiguration der Anwendung selbst zu sichern. K10 verfolgt einen applikationszentrischen Ansatz: Kubernetes verwaltet alle Informationen zu einer laufenden Applikation in Objekten, seien das Config-Maps, Secrets, PVCs oder auch Deployments und Stateful Sets. K10 sichert diese Informationen samt dem Inhalt der persistent Volumes. Schließlich rückte die zunehmende Popularität von Kubernetes die wenigen verfügbaren Backuptools ins Rampenlicht und 2020 übernahm Veeam Kasten und damit das Backupwerkzeug.

Kasten K10 ist heute sowohl als kommerzielle Anwendung als auch als freie Version für kleine Umgebungen mit bis zu fünf Kubernetes-Knoten erhältlich. Testinstallationen dürfen zudem 60 Tage lang bis zu 500 Knoten managen. Da wir ohnehin nur ein überschaubares Setup verwenden, genügte für unseren Test die freie Variante. Wir setzten K10 dabei auf einer Single-Node-OpenShift- und Dual-Node-Rancher-RKE2-Umgebung ein.

Für K10 nutzten wir zwei Testumgebungen: Auf einem bei Hetzner gehosteten Server lief eine Single-Node-Umgebung mit Red Hat OpenShift, das als Basis-Storage-Klassen LVM und NFS verwendete. Dazu gesellte sich eine lokale Rancher-RKE2-Installation auf zwei Lenovo-Notebooks mit Longhorn als CSI-Treiber. Für den S3-Speicher setzten wir, ebenfalls auf einem Hetzner-Server, den S3-Server MinIO in der Variante 250408 ein. Dabei nutzten wir den selben S3-Bucket für beide Kasten-Installationen.

Das Setup von Kasten selbst konnte kaum einfacher sein: Wir nutzten das frei verfügbare Helm-Chart auf unseren beiden Testumgebungen:

Das Chart legte den gewünschten Namespace an und startete alle erforderlichen Pods für Kasten. Damit K10 Snapshots durchführen konnte, benötigten wir noch die passende Snapshot-Class mit der richtigen Annotation. Mit den folgenden Parametern richteten wir diese im Rancher-Setup ein:

Auf dem OpenShift-Setup wiederholten wir den Vorgang leicht abgeändert mit der Snapshot-Class via NFS-CDI-Treiber.

Um die PVs der Applikationen zu sichern, muss K10 für Kubernetes kein eigenes Snapshot-Tool mitbringen, denn das ist unter dem Namen "CSI-Snapshot-Controller" bereits vorhanden. Nahezu jeder CSI-Storage-Driver, egal ob Longhorn, Rook, NFS oder auch nur LVM und Hostpath, bringt seinen eigenen Snapshot-Controller mit.

Zum Thema Snapshots müssen wir aber eine altbekannte Warnung aussprechen: Ein Backup per Volume-Snapshot ist und bleibt unbrauchbar, wenn die Applikation, die in das Volume schreibt, nicht vor dem Snapshot ihren Datenbestand in einen sicheren Zustand versetzt. Bei Datenbanken nennt sich das "Quiescing", das vor einem anwendungskonsistenten Snapshot alle noch im RAM befindlichen Daten in die Datenbankdatei schreibt und diese vorübergehend für Schreibzugriffe schließt. Nun kann ein externes Snapshot-Werkzeug einen konsistenten Snapshot des Volumes erstellen. Das gilt für alle Datenbanken, egal ob sie als SQL oder No-SQL arbeiten.

Als anwendungszentrisches Backuptool achtet K10 natürlich auf die Datenkonsistenz und nutzt dazu sogenannte "Blueprints" die auf der hauseigenen Open-Source-Technologie "Kanister" basieren. Hierbei definierten wir einen oder mehrere "Hooks". Diese führten dann Pre- und Post-Snapshot Kommandos aus, wie beispielsweise pg_start- und -stop_backup in einem PostgreSQL-Container. Hooks können direkt in einem Applikations-Container des Rollouts via "kubeexec" oder in einem extra dafür ausgerollten "Sidecar"-Container laufen.

Mit den passenden Blueprints waren wir in der Lage, unsere Backup-Policy zusammenzustellen. Diese enthielt zunächst alle Objekte, die zu einer Applikation gehören und in der Regel gemeinsam in einem Namespace liegen, wo sie K10 einfach findet. Eine Backup-Policy darf aber auch Ressourcen außerhalb eines Namespaces, wie beispielsweise RBAC-Definitionen und Serviceaccounts, mit in das Backup einbeziehen. Der Policy wiesen wir erst einmal ein "Location Profile" zu – also ein Backup-Target. Dabei unterstützt Kasten alle gängigen Cloudspeicher plus selbstgehosteter S3- oder NFS-Freigaben.

In der Policy erhielten dann einzelne Ressourcen ihren Blueprint, sofern sie einen benötigen. In einer klassischen Webapplikation bekäme beispielsweise nur der Datenbankserver Pre- und Post-Hooks wie zuvor beschrieben, während PODs für Webserver und Loadbalancer in der Regel ohne auskommen. Die Policy kann dabei zwei verschiedene Post-Hooks zuweisen: einen "On Success" und einen "On Failure".

Danach versorgten wir die Policy mit einem Scheduler wie "Hourly" oder "Daily" sowie einem stufenweisen "Verfallsdatum". Bei einer stündlichen Sicherung ist K10 in der Lage, in den ersten 24 Stunden alle Snapshots zu behalten, danach aber nur noch eine Tagessicherung für bis zu sieben Tage und anschließend nur noch eine Wochensicherung.

Veeam Kasten unterstützt nicht nur Applikationen in Pods bei der Sicherung. Die Software kennt sich auch mit Kubevirt und virtuellen Maschinen aus. Um dort das Dateisystem einer Gast-VM vor dem Snapshot in einen sicheren Zustand zu bekommen, greift das Tool auf den QEMU-Gast-Agenten zurück. Vor einem Backup weist K10 den Agenten an, einen Dateisystem-Sync und ein Freeze durchzuführen. Zudem beherrscht der QEMU-Agent sogenannte Hookscripts, die ähnliche Aufgaben wie ein Blueprint in einer VM ausführen.

Die von Kasten K10 erstellten Sicherungen lassen sich nicht nur von dem Kubernetes-Cluster verwenden, der sie erstellt. Gewährten wir Anwender einem anderen Cluster mit K10-Instanz Zugriff auf den S3-Backupspeicher, ließen sich dort gesicherte Applikationen zurücklesen. Damit dient K10 auch als Replikations- und Disaster-Recovery-Tool. Die zugehörigen Restore-/Import-Regeln konnten wir für einen einmaligen Umzug oder mit einem Scheduler für die kontinuierliche Replikation verwenden.

Verfügten Quell- und Ziel-Cluster über verschiedene Ressourcen, bot sich uns die Option, in einer Restore-Policy passende Transform-Sets zu definieren. Diese änderten in den Kubernetes-Objekten einer Applikation dann vor dem Zurücklesen festgelegte Informationen wie den Namen der Storage-Klasse oder eines Netzwerkes. Damit lassen sich Applikationen auch zwischen verschiedenen Kubernetes-Distributionen umziehen. Admins mit einem lokalen Rancher- oder OpenShift-Cluster können somit ihre Applikationen auf einer gehosteten Umgebung bei einem Hyperscaler sichern.

Kasten K10 lässt sich, wie alle anderen Kubernetes-Applikationen, vollständig über YAML-Konfigurationsdateien bedienen und einrichten. Zudem gibt es ein schickes Webinterface mit Dashboard, das eine grafische Konfiguration ermöglicht. Kasten stellt dieses GUI aber nicht von Haus aus via Ingress-Route zur Verfügung, sondern wir mussten es im Basissetup Port-Forwarding auf unsere Arbeitsstation schalten:

Dann gelang der Zugang via "http://localhost:8585/k10/#". Das reichte zwar für unseren Test, taugt aber nicht für den Produktivbetrieb. Hier ist es der beste Weg, eine passende Ingress-Route zu erstellen, die via "htpasswd" als Kubernetes-Secret eine Authentisierung verlangt und eine passende SSL-Terminierung einsetzt. Kommt im Unternehmen die Veeam Data Platform zum Einsatz, sind die Klimmzüge jedoch nicht vonnöten, denn K10 integriert sich in dessen zentrales GUI und lässt sich dann darüber steuern.

Um das Kubernetes-Backup auf Herz und Nieren zu testen, richteten wir auf dem Rancher-Setup zunächst Ansible AWX ein, ebenfalls via Helm-Chart. Wir nutzten AWX, obwohl es seit längerem nicht mehr weiterentwickelt wird, stellvertretend als Webapplikation mit Datenbank. Das stellte sich jedoch problematischer als erwartet heraus.

Die grundlegende Backup-Policy für AWX war schnell aufgesetzt, allerdings ohne Datenbank-Blueprint. Leider fiel zum Testzeitpunkt die Dokumentation über "Kanister" (das Workflow-Managementtool hinter Kasten Blueprints) noch recht dürftig aus und lieferte keine passenden Beispiele für PostgreSQL-Snapshots. Nach einigem Tüfteln fanden wir schließlich die korrekte Vorgehensweise für Pre- und Post-Hooks. Aber dann gesellte sich das Problem hinzu, dass der mit dem AWX-Operator gelieferte PostgreSQL-15-Pod nicht über die korrekten Settings für den Archive-Mode verfügt. Letzten Endes hätten wir also die Datenbank separat aufsetzen, konfigurieren und mit AWX integrieren müssen, um einen konsistenten Snapshot zu erhalten. Für den weiteren Verlauf des Tests verzichteten wir also auf den Hook und dann lief die Sicherung wie geplant durch.

Für den Restore setzten wir eine passende Policy auf dem zweiten Test-Cluster mit OpenShift auf. Ziel war es, das AWX-Setup des Rancher-Clusters auf OpenShift wiederherzustellen. Kasten K10 weist jeder Backup-Policy einen verschlüsselten Import-Key zu. Den kann eine andere Kasten-Instanz mit Zugriff auf den passenden S3-Bucket nutzen, um daraus alle Backupdaten und -konfigurationen zu erhalten. Die passende Restore-Policy stellt dann entweder nur alle Daten auf dem Ziel-Cluster wieder her, ohne dabei die Pods zu starten. Alternativ setzt sie das Setup in Gang und kann dafür auf Wunsch auch alle bereits auf dem Zielsystem bestehenden Ressourcen überschreiben.

Da auf dem Rancher-Cluster Longhorn als CSI-Treiber lief, die OpenShift-Umgebung jedoch NFS nutzte, erstellten wir eine simple Transform-Regel:

Dergestalt war die Kasten-K10-Instanz des OpenShift-Clusters in der Lage, das komplette AWX-Setup samt Operator und dem benötigten Serviceaccount wiederherzustellen. Auf dem OpenShift-Cluster mussten wir dann abermals dem PostgreSQL-Container massiv unter die Arme greifen, da dessen Programmierung und Setup leider wiederholt mit den Sicherheitseinstellungen des OpenShift-Setups kollidierte. Andere Applikationen ließen sich im Test problemlos via Kasten K10 übertragen.

Veeam Kasten K10 geht Backup- und Migrationsaufgaben im Kubernetes-Umfeld korrekt an, da es alle zu einer Applikation gehörenden Daten und Konfigurationen ins Backup einbezieht, selbst wenn diese außerhalb des Namespaces liegen. Besonders gut haben uns die Anpassungsfähigkeiten mit Pre- und Post-Hooks für Snapshots und die Transformer für die Wiederherstellung auf anderen Clustern gefallen. Allerdings könnte Veeam Admins sinnvoll unterstützen, indem es bessere Beispiele zu den Optionen der Kanister-Blueprints zur Verfügung stellt.

Als problematisch stellte sich letzten Endes nicht die Backupanwendung an sich dar, sondern die Art- und Weise wie manche Applikationsentwickler ihre Kubernetes-Anwendungen zusammenstellen. Das von uns gewählte AWX-Setup ließ sich nur mit Einschränkungen sichern und transferieren — was aber kein Problem von K10 ist. Aber es zeigt auf, dass die Betreiber von Kubernetes Anwendungen gegebenenfalls anpassen müssen, um applikationskonsistente Snapshots überhaupt zu ermöglichen. Zudem müssen Admins Zeit und Aufwand in das Entwickeln der passenden Kanister-Blueprints investieren. Veeam Kasten K10 präsentiert sich unter dem Strich als umfassende, aber nicht ganz simple Back-upplattform für Kubernetes, die zudem gute Features für Migration und Disaster Recovery mitbringt.