Backup & Restore
Velero
Velero ist ein quelloffenes Werkzeug für Backup, Restore und Migration von Kubernetes: Es sichert Cluster-Objekte und Volumes per Kubernetes-API in Objektspeicher.
- Backup/Restore für Kubernetes
- Cluster-Objekte und persistente Volumes
- Cluster-Migration über Objektspeicher
- CSI-Snapshots oder File System Backup
- Apache 2.0, CNCF Sandbox
Velero ist ein quelloffenes Werkzeug für Backup, Restore, Disaster Recovery und Migration von Kubernetes. Es entstand als Heptio Ark, kam über VMware zu Broadcom und ist seit 2026 ein CNCF-Sandbox-Projekt (Apache 2.0). Velero arbeitet ausschließlich über die Kubernetes-API und funktioniert daher auch in Managed-Diensten wie EKS, AKS oder GKE, in denen kein direkter etcd-Zugriff besteht.
Dieser Artikel erklärt das Funktionsprinzip (Controller plus CRDs), was Velero sichert und was nicht, die beiden Volume-Backup-Methoden (CSI-Snapshots und File System Backup mit Kopia), Backup-Hooks für anwendungskonsistente Sicherungen, geplante und selektive Backups, die Cluster-Migration sowie die Abgrenzung zu etcd-Backup und zu GitOps.
1. Funktionsprinzip
Velero besteht aus einem Controller, der als Deployment im Cluster läuft, und der CLI velero. Backups, Restores und Zeitpläne werden als CRDs (Custom Resources) im Cluster angelegt und von Controller-Schleifen verarbeitet. Velero fragt die Ressourcen über den API-Server ab, nicht direkt aus etcd, und sichert den deklarativen Zustand (Specs), nicht flüchtige Status-Felder. Cluster-Backups sind dabei nicht streng atomar: Während des Backups erzeugte oder geänderte Objekte können fehlen.
2. Was Velero sichert, und was nicht
Velero sichert zwei Dinge: Kubernetes-API-Objekte (Deployments, Services, ConfigMaps, Secrets, PVCs, RBAC-Regeln, Namespaces) und die persistenten Volumes. Die Backups landen in Objektspeicher (AWS S3, GCS, Azure Blob, S3-kompatibel über MinIO), konfiguriert über die CRD BackupStorageLocation, die sich für Disaster-Recovery-Restores auf read-only setzen lässt.
Velero ersetzt kein etcd-Backup
Velero sichert über die Kubernetes-API, nicht den etcd-Datenbankzustand direkt. Ein etcd-Snapshot (etwa per etcdctl) bildet den Kontrollebenen-Zustand ab und ist ein separater Vorgang. Beide sind komplementär: Velero für Workloads und Daten, etcd-Snapshot für die Control-Plane. Das eine ersetzt das andere nicht.
3. Volume-Backup: CSI-Snapshots vs. File System Backup
Für persistente Volumes gibt es zwei Wege. CSI Volume Snapshots lösen über den CSI-Treiber des Speichersystems native Storage-Snapshots aus, schnell und speichersystemnah, aber providergebunden (ein AWS-EBS-Snapshot ist nicht auf Azure wiederherstellbar). File System Backup (FSB) kopiert die Dateisystemdaten der Pod-Volumes direkt in den Objektspeicher, speicheragnostisch und cross-cloud-tauglich; ausgeführt vom node-agent (einem DaemonSet) mit Kopia als Standard-Uploader (er löste Restic ab). Beide Methoden lassen sich kombinieren.
4. Hooks, Schedules und selektive Backups
Für anwendungskonsistente Sicherungen führt Velero Backup-Hooks aus: Befehle vor (pre) oder nach (post) dem Backup in Pod-Containern, etwa ein Datenbank-Flush vor dem Volume-Snapshot. Schedules planen Backups per Cron-Syntax mit konfigurierbarer Aufbewahrung (TTL). Über selektive Filter lässt sich gezielt sichern, nach Namespaces, Label-Selektoren oder Ressourcentypen; Objekte mit dem Label velero.io/exclude-from-backup werden ausgenommen.
Ohne Hooks ist ein Volume-Backup eines laufenden Datenbank-Pods bestenfalls crash-consistent. Wer Datenbanken in Kubernetes sichert, kommt um pre-/post-Hooks für Flush und Lock nicht herum, sonst sichert man einen möglicherweise inkonsistenten Zustand.
5. Migration und Abgrenzung zu GitOps
Velero kann zwischen Clustern migrieren: Quell- und Ziel-Cluster zeigen auf denselben Objektspeicher, Velero synchronisiert die Backup-Metadaten, anschließend wird im Ziel-Cluster ein Restore ausgeführt (für Cross-Provider per FSB statt CSI). Zur Abgrenzung von GitOps: GitOps-Werkzeuge wie Argo CD oder Flux stellen die in Git deklarierten Manifeste wieder her, kennen aber weder Laufzeitzustand noch Volume-Daten. Velero sichert genau diese zusätzlich. Beide ergänzen sich, GitOps für Konfigurations-Drift, Velero für Datenverlust und Migration.
6. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Kubernetes-nativ, funktioniert auch in Managed-Diensten | Nur Kubernetes, kein Allzweck-Backup für VMs/Bare Metal |
| Sichert API-Objekte und persistente Volumes | Volume-Konsistenz ohne Hooks nicht gewährleistet |
| Cluster-Migration als First-Class-Feature | etcd-Backup bleibt separat erforderlich |
| CSI-Snapshots oder FSB (Kopia), kombinierbar | CSI-Snapshots nicht cross-provider portabel |
| Apache 2.0, CNCF Sandbox, breite Provider-Plugins | Backups nicht streng atomar; kein GUI im Kern |
Häufige Fragen zu Velero
Nein. Velero sichert über die Kubernetes-API Workloads und persistente Volumes, nicht den etcd-Datenbankzustand der Control-Plane. Ein etcd-Snapshot ist ein separater Vorgang. Für vollständige Cluster-Resilienz braucht es beides: Velero für die Workloads, etcd-Snapshots für die Kontrollebene.
In der Regel ja, sie ergänzen sich. GitOps stellt die in Git deklarierten Manifeste wieder her, kennt aber weder Laufzeitzustand noch die Daten in persistenten Volumes. Velero sichert genau diese zusätzlich und ermöglicht Namespace-Restores und Cluster-Migrationen, die GitOps allein nicht abdeckt.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Velero im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.