Velero Backup: Cluster sichern, kein PITR 2026

Constantin, Kubernetes-Betrieb bei Pexon Consulting | 11 Min. Lesezeit | 15.09.2026

TL;DR: velero backup kurz erklärt

Velero Backup ist die Cluster-Ebene: Objekte, optional CSI-Snapshots, kein Datenbank-PITR und kein Auditor-Walkthrough. Pexon Consulting (80 Mitarbeitende, Deutschland, Microsoft Partner) trennt das von Barman, Volume-Backup und etcd. Ein grüner Job ist kein Wiederherstellungsnachweis. Besitz von Job und Drill gehört in den Betrieb.

Das Problem: Der Cron ist grün, der Restore ist ein Gerücht

Jeden Morgen ein erfolgreicher Backup-Job. Das Ticket „Cluster wiederherstellen“ hat niemand in diesem Quartal gezogen. Object-Store-Rechte kennt eine Person, die im Urlaub ist. Postgres hängt am selben Job, „weil Velero die PVCs mitnimmt“.

Genau hier endet velero backup als Strategie und beginnt es als Schicht. Velero sichert Kubernetes. Es sichert nicht die Idee einer Datenbank und nicht den Beweis vor dem Auditor.

Den Walkthrough für den Nachweis schreibt die Seite Restore-Nachweis. Dieser Text sagt nur, welche Ebene Velero ist. Die Härtungs-Checkliste zieht Sicherung-Queries, ersetzt das Lemma aber nicht.

Pexon Consulting hängt die Grenze an den Managed Service: wer besitzt den Job, wer den Drill, wer das Konto im Object-Store.

Was sichert Velero – und was sichert es ausdrücklich nicht?

Velero ist ein Kubernetes-Backup für Cluster-Ressourcen und, über CSI, für Volumes, kein Ersatz für Datenbank-WAL und kein Restore-Nachweis vor dem Auditor. Zielgruppe: Betriebsteams, die klären, was ein Cluster-Backup wirklich zurückholt.

Sichert: Deployments, Services, ConfigMaps, Secrets (Vorsicht Rechte), Namespace-Schnitte, PVC-Objekte, optional Volume-Snapshots. Das ist die Cluster-Ebene.

Sichert nicht: Postgres-PITR, etcd als Control-Plane-Pfad, den geprobten Restore mit Protokoll. Ein erfolgreicher Backup-Job ist kein Wiederherstellungsnachweis.

Stabile Version am 15.09.2026: Velero 1.18.2 (26.06.2026). 1.18.3-rc.2 erschien am 08.09.2026. Für Prod bleiben wir auf 1.18.2. Das Repo vmware-tanzu/velero lag bei 10.294 GitHub-Stars.

# Schicht zeigen, keine Anleitung für Prod. Schedule-Name anpassen.
velero backup-location get
velero backup get
# Ein Completed hier ist kein Drill.

Docs: Velero Backup/Restore. Keine erfundenen Support-Matrizen für jede CSI-Klasse.

Wann reicht Velero, und wann brauchen Sie zusätzlich Barman oder Volume-Backup?

Die kurze Antwort: Velero reicht für den Cluster-Schnitt. Datenbanken und fette Volumes brauchen ihre eigene Ebene.

Stateless Apps, Config, RBAC, die meisten Namespaces: Velero. Postgres mit PITR-Anspruch: Barman über CloudNativePG. Block-Storage mit eigener Snapshot-Klasse: CSI oder Longhorn-Backup zusätzlich, nicht stattdessen.

Unsere Empfehlung: drei Besitzer aufschreiben, nicht drei Tools in einen Cron kippen. Wer „Velero nimmt alles“ sagt, hat die Schichtfrage verschoben, nicht gelöst.

Wann wir davon abraten: Velero als einzige Antwort auf „kubernetes backup“, während die DR-Seite einen anderen Intent trägt. Focus bleibt velero backup, nicht der Head-Term.

Warum ist ein grüner Backup-Cron kein Restore-Nachweis?

Weil der Job beweist, dass Daten weggeschrieben wurden, nicht dass sie zurückkommen. Rechte, Encryption-Key, Namespace-Filter, eine API-Version, die der Restore nicht kennt: alles fällt erst auf, wenn jemand den Drill zieht.

Der Nachweis ist ein geprobter Restore mit Protokoll. Das ist die andere Seite, nicht dieses Lemma. Wir verlinken sie, wir schreiben sie nicht nach.

Wir raten davon ab, den Auditor mit einem Screenshot von Completed zu beruhigen. Das ist die günstigste Form, später teuer zu werden.

Welche Betriebsgrenze gehört in einen Managed Service, nicht in ein Tutorial?

Wer erstellt das Schedule? Wer darf restore? Liegt das Bucket im Kunden-Tenant? Welche Uhrzeit ist das Fenster, Mo-Fr 08:00-18:00 wie auf der Betriebsseite, nicht ein erfundenes 24/7?

Das sind Vertragsfragen. Helm-Werte sind es nicht. Pexon Consulting übernimmt den Recurring-Betrieb für den Cluster, den Sie schon haben. Kein Hosting-Tarif, kein Konfigurator.

etcd-Backup (Talos oder kubeadm) bleibt Control Plane. Velero ersetzt das nicht. Wer nach einem etcd-Verlust nur Velero hat, restauriert Apps in ein Cluster, das seine API verloren hat.

Wie wir velero backup in einem bestehenden Cluster schneiden

Velero Backup nachrüsten ist einfach. Es zu besitzen ist die Arbeit. In einem Cluster, der schon Last trägt, gehen wir so vor:

1. Backup-Location und Credentials. Kunden-Tenant, nicht ein geteiltes Demo-Bucket.
2. Schedule pro Namespace-Klasse, nicht ein „alles“-Job, der Secrets und kube-system ungefiltert mitnimmt.
3. CSI-Snapshot nur dort, wo die Klasse es kann. Sonst lügt der Job mit Completed und leerem Volume.
4. Ausschluss von Dingen, die Barman oder Longhorn schon sichern. Doppelte Jobs, geteilte Verwirrung.
5. Ein Restore-Fenster im Kalender. Ohne Datum bleibt der Drill ein Vorsatz.

Was dieser Text nicht wird: ein Auditor-Walkthrough. Den trägt die Restore-Seite. Was er nicht wird: ein Head-Term-Artikel zu kubernetes backup. DataForSEO nannte am 15.09.2026 velero backup mit 140 Suchen, die Marke velero mit 3600 (LOW), kubernetes backup mit 70. Focus bleibt die Phrase velero backup.

Hardening-Blogs ziehen Sicherung-Queries. Deshalb hier keine zweite Checkliste. Ein Satz reicht: CIS fragt, ob Backup existiert. Velero beantwortet die Cluster-Ebene. Den Rest beantworten andere Tools.

1.18.3-rc.2 vom 08.09.2026 ist nah. Prod bleibt 1.18.2, bis der stabile Patch da ist. Wer RCs in Prod fährt, kauft die Findings selbst.

Pexon Consulting hängt den Besitz an den Managed Service, Mo-Fr 08:00-18:00 wie die live Seite. Kein Hosting, kein Konfigurator, kein 24/7. Wer nachts einen Restore braucht, muss das gesondert klären, nicht aus diesem Lemma ableiten.

Namespace-Filter sind die Stelle, an der Teams sich selbst täuschen. Ein Schedule „alles außer kube-system“ klingt erwachsen und nimmt trotzdem Secrets mit, die ein zweites Team nicht sehen darf. Oder es lässt genau das Namespace aus, in dem die Fachanwendung liegt, weil jemand ein Label falsch gesetzt hat. Deshalb lesen wir das Schedule, bevor wir den Job loben.

Volume-Snapshots ohne getestete Klasse erzeugen den Completed-Job mit leerer Disk. Das ist schlimmer als kein Job, weil das Dashboard beruhigt. CSI-Fähigkeit schriftlich, sonst nur Objekte sichern und Volumes ehrlich den anderen Ebenen überlassen.

etcd bleibt der Satz, den wir wiederholen, weil er in Reviews am häufigsten fehlt. Velero spricht mit der API. Ist die API weg, spricht niemand. Talos- oder kubeadm-etcd-Backup ist ein anderes Briefing, hier nur die Grenze.

Retention im Bucket und Retention im Schedule müssen dieselbe Geschichte erzählen. Sieben Tage im Job, neunzig Tage im Bucket ohne Lifecycle: jemand zahlt Storage und nennt es Sicherheit. Umgekehrt: Bucket löscht nach drei Tagen, Schedule verspricht einen Monat. Beides Finding.

Verschlüsselung client-seitig oder bucket-seitig: eine Entscheidung, schriftlich. Ein offenes Bucket mit Cluster-Secrets ist kein Backup, das ist eine Veröffentlichung mit Verzögerung.

1.18.2 bleibt Prod. Den RC vom 08.09.2026 erwähnen wir als Frische, nicht als Aufforderung. Stars 10.294 am 15.09.2026, Repo vmware-tanzu/velero.

Ein Restore-Test, der nur ConfigMaps zurückholt, beweist den Job, nicht die Anwendung. Fachliche Daten gehören in die Ebene, die sie versteht. Velero Backup bleibt die Cluster-Ebene. Wer das im Kickoff nicht trennt, erklärt später dem Fachbereich, warum der Namespace da ist und die Datenbank nicht. Im Managed Service schreiben wir die Trennung in die Betriebsgrenze, bevor der erste Cron läuft. velero backup ohne diese Trennung bleibt ein grüner Job und eine rote Überraschung. Object-Store, Schedule und Drill haben drei Besitzer oder einen Vertrag, der die drei nennt. Ein Cron allein ist keines von beiden. velero backup in 1.18.2, Stars 10.294 am 15.09.2026, ist der Stand. Der Drill bleibt der Beweis. Der Managed Service bleibt der Funnel, kein Hosting.

Häufig gestellte Fragen

Was kostet velero backup?

Open Source. Geld sitzt in Object-Store, CSI-Klasse, Übungen und dem Menschen, der den Job besitzt. Einen Chart-Preis von uns gibt es nicht. Der Betrieb hängt am Managed Service.

Sichert Velero etcd?

Nein. etcd ist die Control Plane, ein eigener Pfad. Velero sichert Ressourcen über die API, solange die API antwortet.

Velero oder Longhorn-Backup?

Andere Ebene. Longhorn hält Volumes. Velero hält den Cluster-Schnitt. Beides kann nötig sein. Eins als Ersatz für das andere ist die falsche Sparsamkeit.

Reicht Velero für Postgres?

Für das Namespace-Objekt ja. Für PITR nein. Barman bleibt die Datenbank-Ebene.

Ist ein Completed-Job ein Nachweis für den Auditor?

Nein. Nachweis ist der geprobte Restore. Den beschreibt die Restore-Seite, nicht dieser Text.

Nächster Schritt

Verwandte Themen