AKS Backup 2026: Velero, Longhorn, Barman oder Azure?

Constantin Budin, Plattformberater bei Pexon Consulting | 11 Min. Lesezeit | 29.09.2026

TL;DR: AKS Backup in vier Ebenen

Ein AKS Backup ist kein einzelnes Werkzeug, sondern vier Ebenen: Cluster-Objekte, Volumes, Datenbank und Datei-Shares. Velero oder Azure Backup for AKS sichern den Cluster-State, Longhorn die Block-Volumes, CloudNativePG mit Barman die Postgres-Zeitpunkte. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) legt pro Ebene fest, wer sichert und wer den Restore übt.

Das Problem: Jede Ebene ist gesichert, aber niemand kennt die Reihenfolge

In fast jedem Review-Gespräch zu hybriden Plattformen fällt derselbe Satz in einer anderen Form: Backups laufen, aber wie ein Restore genau abläuft, weiß keiner. Im letzten Review stand es wörtlich auf der Liste der offenen Punkte: unklare Backup- und Restore-Prozesse.

Das liegt selten an fehlender Technik. Meist gibt es sogar zu viel davon. Der Fileserver hat sein eigenes Backup, Azure Local hat Snapshots, im Cluster läuft ein Velero-Schedule, und die Datenbank macht nächtliche Dumps. Jedes Werkzeug meldet grün. Nur die Frage, welche Ebene nach einem Ausfall zuerst zurückkommt und welche Daten dann zusammenpassen, beantwortet keines davon.

Genau diese Entscheidung ist der Kundenjob, nicht der Nachweis danach. Wie Sie einen geübten Restore für den Auditor dokumentieren, beschreiben wir auf der Seite zum Restore-Nachweis für Kubernetes. Dieser Text setzt eine Stufe früher an: Welche Ebene sichert was, und welches Werkzeug gehört wohin?

Eine Warnung vorweg: Wir nennen in diesem Text keine RPO- oder RTO-Werte. Die hängen an Ihrem Geschäft, nicht an einem Werkzeug. Wer sie aus einem Blog übernimmt, übernimmt die Annahmen eines Fremden.

Was sichert ein AKS Backup, das ein Fileserver-Backup nicht sichert?

Ein AKS Backup sichert den Zustand des Clusters: welche Workloads laufen, mit welcher Konfiguration, welchen Secrets und welchen Volume-Bindungen. Ein Fileserver-Backup sichert Dateien. Wer nur Dateien hat, kann nach einem Clusterverlust die Daten zurückspielen, aber nicht die Anwendung, die sie liest.

Der Cluster-State umfasst mehr, als die meisten Teams zuerst aufschreiben:

• Namespaces, Deployments, StatefulSets, Services und Ingress-Regeln
• Secrets und ConfigMaps, also auch Zertifikate und Zugangsdaten
• Custom Resources von Operatoren, etwa Cluster-Definitionen für Datenbanken
• PersistentVolumeClaims mit ihrer Bindung an Storage-Klassen
• RBAC-Rollen und ServiceAccounts

Liegt das alles in Git, weil Sie per GitOps deployen, ist ein Teil davon schon gesichert. Aber nicht alles: Secrets aus einem externen Vault, Objekte, die Operatoren zur Laufzeit erzeugen, und manuelle Hotfixes stehen nicht im Repository. Aus unserer Sicht ist GitOps deshalb eine Ebene des Backups, kein Ersatz dafür.

Die Datei-Ebene bleibt, wo sie ist. Freigaben auf dem Fileserver sichert weiter das Werkzeug, das dort heute läuft. Den Fileserver in den Cluster zu ziehen, nur damit ein Werkzeug alles sichert, halten wir für einen Umweg ohne Gewinn.

Wann reicht Azure Backup for AKS, und wann brauchen Sie Velero?

Azure Backup for AKS reicht, wenn Ihr Cluster in Azure läuft und die Volumes auf Azure Disk liegen. Velero brauchen Sie, sobald Volumes außerhalb dieser Liste liegen, der Cluster on-prem oder auf Azure Local läuft oder Sie in einen Cluster bei einem anderen Anbieter wiederherstellen wollen.

Azure Backup for AKS ist der Haken im Portal. Er installiert eine Backup-Erweiterung im Cluster, braucht einen Storage-Account mit Blob-Container und verwaltet Richtlinien im Backup-Vault. Die Grenzen stehen in der Support-Matrix von Microsoft und sind enger, als der Haken vermuten lässt:

Zwei Grenzen treffen hybride Umgebungen besonders. Azure-Files-Freigaben werden nur über öffentliche Endpunkte gesichert, und bei mehr als 25.000 Dateien pro Freigabe kann der Restore scheitern. Wer Azure Files mit Private Endpoints betreibt, hat damit für diese Volumes kein AKS-Backup, obwohl der Haken gesetzt ist.

Velero ist das Werkzeug, das überall läuft. Die aktuelle Version 1.18.3 ist am 08.09.2026 erschienen, Kopia ist der Standard für Dateisystem-Backups. Was Velero im Detail sichert und warum es keinen Datenbank-Zeitpunkt liefert, steht in unserem Beitrag zu Velero Backup für den Cluster-State. Ein nächtlicher Schedule für den Cluster-State sieht so aus:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: cluster-state-nightly
  namespace: velero
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces: ["*"]
    excludedNamespaces: ["kube-system", "velero"]
    snapshotVolumes: false        # Volumes sichert eine andere Ebene
    ttl: 720h0m0s                 # 30 Tage

Unsere klare Empfehlung für AKS: Azure Backup for AKS für Azure-Disk-Volumes nutzen, wenn es passt, und Velero trotzdem für den Cluster-State in einen eigenen Bucket schreiben lassen. Dann hängt der Restore nicht an einem Abo, das beim Vorfall vielleicht selbst betroffen ist.

Wann sichert Longhorn, und wann ein Velero-Snapshot?

Longhorn sichert Block-Volumes auf eigenem Storage, typischerweise on-prem oder auf Azure Local, wo es keine Cloud-Disk mit Snapshot-API gibt. Velero-Snapshots sind die bessere Wahl, wenn die Volumes auf Azure Disk liegen und der CSI-Treiber Snapshots liefert. Beides gleichzeitig für dasselbe Volume ist doppelte Arbeit ohne doppelten Schutz.

Longhorn schreibt Backups auf NFS, S3, CIFS oder Azure Blob. Seit Version 1.8 kann ein Cluster mehrere Backup-Ziele haben. Ein Volume hängt aber an genau einem Ziel, und ein wiederkehrender Backup-Job kann sein Ziel nicht selbst wählen. Wer eine zweite Kopie an einem anderen Ort braucht, löst das eine Ebene tiefer, etwa über Replikation des Buckets.

Die Aufteilung, die wir in hybriden Projekten meist setzen:

1. Velero: Cluster-State aller Namespaces, ohne Volume-Daten.
2. Longhorn Backup: Block-Volumes der zustandsbehafteten Anwendungen auf eigenem Storage.
3. Datenbank-Werkzeug: alles, was einen Zeitpunkt braucht, also Postgres.

Damit Velero Datenbank-Volumes nicht versehentlich doppelt sichert, markieren wir sie explizit:

# Postgres-PVCs aus dem Velero-Backup nehmen, Barman ist zuständig
kubectl label pvc -n app-db -l cnpg.io/cluster=app-db \
  velero.io/exclude-from-backup=true

Wie Longhorn als Block-Storage statt local-path aufgebaut wird, beschreiben wir im Beitrag zu Longhorn in Kubernetes.

Warum Postgres einen eigenen Weg braucht: CloudNativePG und Barman

Ein Volume-Snapshot einer laufenden Datenbank ist ein Abbild der Platte, kein Abbild der Transaktionen. Für einen Restore auf einen bestimmten Zeitpunkt, etwa fünf Minuten vor einem fehlerhaften Deployment, brauchen Sie ein Base Backup plus die WAL-Dateien dazwischen. Das liefert bei CloudNativePG das Barman-Backup, nicht Velero und nicht Longhorn.

Hier steht 2026 ein Umbau an, den viele Teams noch nicht eingeplant haben. Die in den Operator eingebaute Barman-Unterstützung ist seit CloudNativePG 1.26 abgekündigt und fällt mit Version 1.31 weg. Die Hinweise dazu stehen seit Release 1.28.4 vom 29.06.2026 in den Release Notes. Der Nachfolger ist das Barman Cloud Plugin, das als Sidecar im Datenbank-Pod läuft und WAL-Archivierung und Point-in-Time-Recovery übernimmt.

Die Umstellung besteht aus zwei Objekten: einem ObjectStore für das Ziel und einem Plugin-Eintrag im Cluster:

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
  name: pg-backup
  namespace: app-db
spec:
  configuration:
    destinationPath: https://<storage-account>.blob.core.windows.net/pg-backup
    azureCredentials:
      inheritFromAzureAD: true
  retentionPolicy: "30d"
---
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: app-db
  namespace: app-db
spec:
  instances: 3
  plugins:
    - name: barman-cloud.cloudnative-pg.io
      isWALArchiver: true
      parameters:
        barmanObjectName: pg-backup

Wer noch spec.backup.barmanObjectStore im Cluster-Manifest stehen hat, sollte die Migration vor dem Upgrade auf 1.31 testen, nicht danach. Wir raten dazu, den ersten Restore aus dem Plugin-Backup in einen Test-Namespace zu fahren, bevor die alte Konfiguration verschwindet.

Läuft die Datenbank nicht im Cluster, sondern als Azure Database for PostgreSQL, gilt eine einfachere Regel: Der Dienst bringt eigene Point-in-Time-Recovery mit, und das Cluster-Backup muss nur die Verbindungsdaten kennen. Wie Postgres im Cluster hochverfügbar statt als Einzel-Pod läuft, zeigt unsere Seite zu Postgres HA in Kubernetes.

Warum der Restore-Nachweis die andere Seite ist

Die Entscheidung, welche Ebene was sichert, ist die eine Seite. Der Nachweis, dass ein Restore in der geplanten Reihenfolge funktioniert, ist die andere. Beide gehören zusammen, aber sie beantworten verschiedene Fragen: Die Matrix sagt, was zurückkommen soll. Der Nachweis zeigt, dass es zurückkam.

Die Reihenfolge nach einem Totalausfall folgt den Ebenen von unten nach oben:

1. Storage und Netz verfügbar, auf Azure Local oder in Azure.
2. Cluster-State per Velero zurück, ohne Datenbank-Volumes.
3. Datenbank per Barman auf den gewünschten Zeitpunkt.
4. Anwendungen starten gegen die wiederhergestellte Datenbank.
5. Datei-Shares separat prüfen, falls Anwendungen darauf zugreifen.

Ein grüner Backup-Job beweist keinen dieser Schritte. Aus unserer Sicht gehört mindestens ein vollständiger Restore pro Quartal in einen Test-Cluster in den Betriebsplan, mit Datum, Dauer und Ergebnis. Wie das im laufenden Betrieb aussieht, beschreiben wir auf der Seite zu Kubernetes Backup und Restore als Betrieb. Für die Azure-Seite außerhalb des Clusters, etwa Ransomware-Schutz für VMs und Freigaben, gibt es unsere Seite zu Azure Backup und Disaster Recovery.

Häufig gestellte Fragen

Reicht der Hyperscaler-Backup-Haken für den Cluster?

Für einen AKS-Cluster mit Volumes auf Azure Disk deckt Azure Backup for AKS den Cluster-State und die Disks ab. Er deckt keine Azure-Files-Freigaben hinter Private Endpoints, keine NetApp- oder Fremd-Volumes und keinen Datenbank-Zeitpunkt ab. Für Cluster auf Azure Local oder on-prem greift er gar nicht.

Ist Velero dasselbe wie ein AKS Backup?

Velero ist ein Werkzeug für das AKS Backup, nicht das ganze Backup. Es sichert Kubernetes-Objekte und auf Wunsch Volume-Daten, läuft aber auch außerhalb von Azure. Den konsistenten Datenbank-Zeitpunkt liefert Velero nicht, dafür braucht Postgres Barman oder die PITR des Managed-Dienstes.

Brauche ich Longhorn Backup, wenn ich Velero habe?

Nur, wenn Ihre Volumes auf Longhorn liegen, also meist on-prem oder auf Azure Local. Dort ist Longhorn Backup meist der robustere Weg für Block-Volumes. Auf Azure Disk übernimmt der CSI-Snapshot diese Aufgabe, und Longhorn ist nicht im Spiel.

Was ändert sich mit CloudNativePG 1.31 beim Backup?

Die eingebaute Barman-Unterstützung fällt weg. Backups und WAL-Archivierung laufen dann nur noch über das Barman Cloud Plugin mit einem eigenen ObjectStore. Wer das alte Feld barmanObjectStore nutzt, muss vor dem Upgrade migrieren und den Restore aus dem neuen Backup einmal testen.

Was kostet es, die Backup-Ebenen sauber aufzusetzen?

Die Werkzeuge selbst sind Open Source oder im Azure-Abo enthalten, Kosten entstehen für Speicher und Aufwand. Den größten Teil macht der erste geübte Restore aus, nicht die Konfiguration. Unser Managed Kubernetes startet ab 2.500 EUR im Monat, den Umfang für Ihren Cluster klären wir im unverbindlichen Cluster-Check.

Nächster Schritt

Verwandte Themen