Velero: Backup & Disaster Recovery für DORA und NIS-2

TL;DR

• Velero ist ein ausgereiftes Open-Source-Werkzeug für Backups, Migrationsszenarien und Disaster Recovery in Kubernetes-Umgebungen – und damit ein zentraler Baustein für jede belastbare Compliance-Architektur.
• Regulatorische Vorgaben wie GDPR (seit dem 25.05.2018 anwendbar), NIS‑2 (Umsetzung bis zum 17.10.2024) und DORA (gilt ab dem 17.01.2025) verlangen explizit robuste Business-Continuity- und Wiederherstellungskonzepte – nicht nur Backups „irgendwo im S3-Bucket“.
• Eine stimmige Backup-Strategie umfasst automatisierte, richtlinienbasierte Backups, geografisch getrenkte und verschlüsselte Speicherung, klare RPO/RTO-Ziele sowie regelmäßig geübte Restore- und Disaster-Recovery-Prozesse.
• Velero wird in kritischen Szenarien – vom Verlust eines Namespaces bis hin zum kompletten Cluster-Ausfall – zum operativen Herzstück des DR-Prozesses und verbindet technische Wiederherstellung mit regulatorisch sauberer Dokumentation.
• ayedo liefert eine integrierte Lösung: Die ayedo Kubernetes Distribution bringt Velero, Offsite-Storage, Monitoring und standardisierte DR-Prozesse als Bausteine mit – inklusive Beratung zur Ausrichtung an GDPR, NIS‑2 und DORA.

---

Velero im Überblick: Backup- und Migrations-Engine für Kubernetes

In produktiven Kubernetes-Landschaften ist ein robustes Backup- und Disaster-Recovery-Konzept keine Kür mehr, sondern eine regulatorische Pflicht. Velero hat sich hier als De-facto-Standard etabliert.

Was Velero leistet

Velero adressiert drei Kernaufgaben:

1. Backup von Cluster-Ressourcen
   Dazu gehören Deployments, StatefulSets, Services, ConfigMaps, Secrets und sämtliche Objekte im Kubernetes-API-Server. Velero sichert nicht nur „Daten“, sondern den vollständigen Anwendungszustand.

2. Backup von Persistent Volumes
   Über CSI-Snapshots oder dateibasierte Backups werden persistente Volumes gesichert. Damit lassen sich komplette Workloads – inklusive Datenbanken – konsistent wiederherstellen, ergänzt um datenbankspezifische Verfahren, wo notwendig.

3. Migration und Replikation von Workloads
   Backups können in anderen Clustern wiederhergestellt werden. Das ist hilfreich:

   • für DR-Cluster in einem zweiten Rechenzentrum,
   • für Cloud-Migrationen,
   • für Test-Wiederherstellungen ohne Einfluss auf Produktion.

Velero arbeitet typischerweise mit S3-kompatiblen Object-Stores, ist cloud-agnostisch und fügt sich nahtlos in bestehende Plattform-Architekturen ein. In einer regulierten Umgebung wird es damit zur kritischen Komponente der gesamten Disaster-Recovery-Strategie.

---

Regulatorische Anforderungen: NIS‑2, DORA und GDPR im Backup-Kontext

Die europäische Regulatorik verlangt explizit mehr als „wir haben irgendwo Snapshots“.

GDPR / DSGVO: Verfügbarkeit und Belastbarkeit

GDPR Art. 32 fordert seit dem 25.05.2018 ein angemessenes Schutzniveau für personenbezogene Daten, einschließlich Schutz vor „unbeabsichtigter oder unrechtmäßiger Vernichtung oder Verlust“.
Konkret bedeutet das:

• Backups für alle Systeme, die personenbezogene Daten verarbeiten,
• Prozesse zur zeitnahen Wiederherstellung der Verfügbarkeit,
• dokumentierte technische und organisatorische Maßnahmen (TOMs),
• regelmäßige Überprüfung der Wirksamkeit dieser Maßnahmen.

Velero adressiert hier vor allem:

• den technischen Wiederherstellungspfad,
• die Nachvollziehbarkeit von Backups (Logs, Status),
• die Möglichkeit, Wiederherstellungstests reproduzierbar zu fahren.

NIS‑2: Business Continuity und Backup-Management

Die NIS‑2-Richtlinie (NIS‑2, Richtlinie (EU) 2022/2555) muss bis zum 17.10.2024 in nationales Recht überführt sein. Sie verlangt für „wichtige“ und „wesentliche“ Einrichtungen u. a.:

• Business-Continuity-Konzepte, einschließlich
  • Backup-Management,
  • Disaster-Recovery,
  • Krisenkommunikation.
• Maßnahmen zur Sicherstellung von Verfügbarkeit und Wiederherstellbarkeit kritischer Dienste.

Für Kubernetes-Plattformen bedeutet das:

• definierte RPO/RTO-Ziele für alle kritischen Workloads,
• regelmäßige und überwachte Backups,
• dokumentierte DR-Pläne,
• regelmäßige DR-Übungen.

Velero wird hier zum operativen Werkzeug, das diese Anforderungen technisch abbildet und über Monitoring nachvollziehbar macht.

DORA: BCP/DR als gelebter Prozess

Die Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554) tritt am 17.01.2025 vollständig in Kraft. Sie richtet sich insbesondere an Finanzunternehmen und deren IT-Dienstleister.

Im Kern fordert DORA:

• ausgereifte Business-Continuity- und Disaster-Recovery-Pläne (BCP/DR),
• klare Verantwortlichkeiten und Eskalationswege,
• regelmäßige Tests – vom einfachen Restore bis zu komplexen Szenario-Übungen,
• Nachweis der operational resilience gegenüber Aufsichtsbehörden.

Für Kubernetes-Umgebungen heißt das:

• ein dokumentierter End-to-End-Prozess vom Ausfall bis zur Wiederherstellung,
• technische Werkzeuge wie Velero, die standardisierte, reproduzierbare Wiederherstellung ermöglichen,
• Metriken und Reports, die Resilienz messbar machen.

---

Backup-Strategie für regulierte Kubernetes-Umgebungen

Ein Werkzeug wie Velero entfaltet seine Wirkung erst in einer klar definierten Strategie. Die folgenden Elemente sind in regulierten Umgebungen essenziell.

Was gesichert werden muss

1. Kubernetes-Objekte
   Alle Ressourcen, die den Zustand Ihrer Anwendungen definieren:

   • Namespaces, Deployments, StatefulSets, Services, Ingress,
   • ConfigMaps, Secrets, Custom Resources (z. B. Operators).

2. Persistente Daten

   • Volumes, auf denen Datenbanken oder State-full Services laufen,
   • Dateien, Reports, Logs, die regulatorisch relevant sind.

3. Cluster-Metadaten und -Konfiguration

   • Cluster-weite Konfigurationen,
   • RBAC-Rollen und -Bindings,
   • Netzwerk-Policies.

4. Datenbankspezifische Backups
   Velero kann nicht alle Eigenheiten von PostgreSQL, MariaDB, MongoDB etc. allein abbilden. Hier ergänzen:

   • datenbankspezifische Backuptools (z. B. WAL-Archivierung, Binary Logs),
   • konsistente Koordination mit Velero-Backups,
   • zentrale Überwachung aller Backup-Jobs.

Frequenz, RPO und RTO

Regulatorik zwingt zur Klarheit:

• Recovery Point Objective (RPO): Wie viele Minuten/Stunden Datenverlust sind akzeptabel?
• Recovery Time Objective (RTO): Wie lange darf die Wiederherstellung kritischer Systeme dauern?

Typische Muster:

• Tägliche Standard-Backups (RPO ≈ 24 h) für nicht-kritische Workloads,
• mehrfache tägliche oder stündliche Backups für kritische Anwendungen,
• zusätzliche On-Demand-Backups vor Releases, Schema-Änderungen oder größeren Plattformupdates.

Velero erlaubt hierfür mehrere Schedules pro Namespace oder Workload-Klasse und unterstützt so fein granulierte RPO-Strategien.

Speicher-Architektur: Offsite, verschlüsselt, nachvollziehbar

Für NIS‑2 und GDPR ist die Wahl der Backup-Zielumgebung entscheidend:

• Geografisch getrennte Rechenzentren
  Primärer Cluster in RZ A, Backups in RZ B (mindestens zweistelliger Kilometerabstand).
  Bei regulatorisch besonders sensiblen Setups zusätzlich ein dritter Standort.

• S3-kompatibler, verschlüsselter Object Storage

  • AES-verschlüsselte Buckets,
  • idealerweise WORM/Immutability-Features gegen Ransomware,
  • versionierte Buckets, um versehentliche Löschungen abzufangen.

• Netzwerk- und Rechte-Design

  • minimaler Zugriff auf Backup-Speicher (Least Privilege),
  • strikte Trennung von Produktions- und Backup-Credentials,
  • zentrale Protokollierung aller Zugriffe.

Velero lässt sich so konfigurieren, dass alle Backups automatisch in diese Offsite-Umgebung geschrieben werden – transparent für die Workloads.

Monitoring, Alerting und Governance

Ein Backup, von dem niemand weiß, ob es läuft, erfüllt keine Compliance-Anforderungen.

Wesentliche Elemente:

• Dashboards

  • Überblick über erfolgreiche/fehlgeschlagene Backups,
  • Volumen der Backups,
  • Laufzeiten und Trends.

• Alerting

  • Alarme bei fehlgeschlagenen Backups,
  • Alarme bei ausbleibenden Backups (z. B. keine erfolgreichen Backups in den letzten 25 Stunden),
  • Alarme bei Storage-Engpässen.

• Dokumentierte Policies

  • Retention-Zeiten (täglich, wöchentlich, monatlich, ggf. jährliche Langzeit-Backups),
  • verantwortliche Rollen (z. B. „Backup Owner“ pro kritischer Applikation),
  • Freigabeprozesse für Änderungen am Backup-Setup.

---

Velero als kritische Komponente für Disaster Recovery

Velero ist kein „nice to have“-Tool, sondern in vielen Architekturen der operative Kern des Disaster-Recovery-Prozesses.

Rolle in typischen DR-Szenarien

1. Verlust einzelner Namespaces oder Applikationen

   • Granulare Restores auf Namespace- oder Ressourcenebene,
   • schnelle Rückkehr zum letzten konsistenten Zustand,
   • minimaler Einfluss auf andere Workloads.

2. Korruption von Daten durch Applikationsfehler

   • Wiederherstellung auf einen früheren Stand (z. B. vor einem fehlerhaften Release),
   • Kombination mit datenbankseitiger Point-in-Time-Recovery.

3. Totalverlust eines Clusters oder Rechenzentrums

   • Wiederherstellung der Workloads in einem Standby- oder neu aufgesetzten Cluster,
   • automatisierte Rekonstruktion der Kubernetes-Ressourcen aus dem Offsite-Backup,
   • schrittweise Wiederherstellung kritischer Services nach Priorität.

In all diesen Szenarien ist Velero das Werkzeug, mit dem Sie aus Backups konkrete, lauffähige Services machen.

Zusammenspiel mit Datenbank-Backups

Kritische Datenbanken erfordern zusätzliche Mechanismen (z. B. WAL- oder Binary-Log-Archivierung). Der DR-Prozess sieht dann typischerweise so aus:

• Kubernetes-Ressourcen (Deployments, Services, PVC-Bindings) werden über Velero wiederhergestellt.
• Die Datenbanken selbst setzen auf ihre eigenen Backups und Replikationsmechanismen auf.
• Monitoring und Governance betrachten beide Ebenen gemeinsam.

So entsteht ein integriertes, auditierbares Bild der Resilienz.

---

Praktisches Beispiel: Disaster-Recovery-Prozess für Kubernetes-Workloads

Wie sieht ein realistischer DR-Prozess aus, der GDPR, NIS‑2 und DORA adressiert und Velero als Kernkomponente nutzt?

1. Vorbereitung (Pre-DR)

Bereits vor einem Vorfall müssen folgende Bausteine stehen:

• Klassifikation der Workloads

  • Kritische, hochkritische und weniger kritische Anwendungen,
  • jeweilige RPO/RTO-Ziele und regulatorische Relevanz.

• Standardisierte Backup-Policies

  • Schedules pro Klasse (z. B. stündlich für hochkritische Workloads),
  • definiertes Offsite-Ziel,
  • getestete Retention-Regeln.

• Technische Basis

  • Velero im Cluster produktiv integriert,
  • Zugang zu einem separaten DR-Cluster bzw. der Fähigkeit, einen solchen schnell aufzubauen,
  • zentralisiertes Monitoring und Alerting.

• Dokumentierte Runbooks

  • Schritt-für-Schritt-Anleitungen für Restore und DR-Szenarien,
  • klar definierte Rollen und Eskalationswege.

2. Incident: Erkennung und Entscheidung

Bei einem schwerwiegenden Incident (z. B. Ransomware-Verdacht, Storage-Korruption, RZ-Ausfall) geschieht:

1. Incident Detection: Monitoring oder Security-Team schlägt Alarm.
2. Assessment:
   • Umfang des Schadens,
   • betroffene Workloads und Daten,
   • Einschätzung, ob ein Restore oder ein Failover in ein anderes RZ notwendig ist.
3. Entscheidung: Aktivierung des DR-Plans durch das verantwortliche Gremium (z. B. IT-Notfallstab).

3. Technische Wiederherstellung mit Velero

Im DR-Cluster oder im neu aufgesetzten Cluster:

1. Cluster bereitstellen

   • Kubernetes-Cluster entsprechend der Standard-Konfiguration bereitstellen,
   • grundlegende Infrastruktur-Komponenten (CNI, Ingress, CSI) aktivieren.

2. Velero konfigurieren

   • Anbindung an das bestehende Offsite-Backup-Repository,
   • Zugriff über gesicherte Credentials mit minimalen Rechten.

3. Backups auswählen

   • Auswahl eines geeigneten Backups gemäß RPO-Anforderungen,
   • ggf. Abwägung zwischen minimalem Datenverlust und minimaler Wiederherstellungszeit.

4. Schrittweise Wiederherstellung

   • Zuerst Plattform-nahe Services (z. B. Datenbankcluster, zentrale Services),
   • dann geschäftskritische Applikationen,
   • abschließend weniger kritische Workloads.

5. Datenbank-Restores koordinieren

   • Nach Wiederherstellung der Kubernetes-Ressourcen:
     • Einspielen der aktuellen Datenbank-Backups,
     • ggf. Point-in-Time-Recovery je nach Fehlerbild.

4. Validierung und Umschalten

Nach der technischen Wiederherstellung:

• Validierung

  • Funktionstests kritischer Geschäftsprozesse,
  • Stichproben auf Datenkonsistenz,
  • Security-Checks (insbesondere bei vorherigem Angriffsverdacht).

• Umschalten des Traffics

  • Aktualisierung von DNS, Load Balancern oder Routing-Regeln,
  • schrittweises Hochfahren von Last, um Engpässe frühzeitig zu erkennen.

• Dokumentation für Compliance

  • Zeitabläufe (wann wurde was wiederhergestellt?),
  • Abweichungen von RPO/RTO-Zielen,
  • Lessons Learned für zukünftige Optimierungen.

5. Regelmäßige DR-Übungen

Um DORA- und NIS‑2-Anforderungen zu erfüllen, muss dieser Prozess regelmäßig geübt werden:

• monatliche Stichprobentests einzelner Restores,
• quartalsweise Wiederherstellung kompletter Namespaces in Testumgebungen,
• jährliche End-to-End-DR-Übungen inklusive Business-Stakeholdern.

Velero ermöglicht es, solche Übungen reproduzierbar und mit vertretbarem Aufwand zu fahren – ein entscheidender Faktor bei knappen Engineering-Ressourcen.

---

Häufige Fragen

1. Reicht eine hochverfügbare Storage-Lösung nicht aus, um DORA und NIS‑2 zu erfüllen?

Hochverfügbarkeit ist wichtig, ersetzt aber keine Backups.
Replikation sorgt dafür, dass Daten im Fehlerfall weiter verfügbar sind – sie repliziert jedoch auch Fehler, Korruption und Löschoperationen.

Regulatoren wie in NIS‑2 und DORA erwarten:

• getrennte, versionsfähige Backup-Kopien,
• Offsite-Standorte,
• dokumentierte Restore-Prozesse,
• regelmäßige Wiederherstellungstests.

Velero adressiert genau diesen Teil: Es erzeugt eigenständige Backup-Artefakte, die unabhängig von der Produktionsumgebung verwaltet und wiederhergestellt werden können.

2. Wie oft müssen wir Restore- und DR-Tests durchführen?

Die Verordnungen geben selten exakte Intervalle vor, verlangen aber „regelmäßige“ Tests und einen risikoorientierten Ansatz. In der Praxis haben sich etabliert:

• monatliche Stichproben einzelner Restores,
• quartalsweise Wiederherstellung ganzer Namespaces in Test-Clustern,
• jährliche, umfassende DR-Übung mit Beteiligung von Business und Management.

Entscheidend ist, dass Sie:

• dokumentieren, wann und wie getestet wurde,
• die Ergebnisse und Abweichungen von RPO/RTO festhalten,
• daraus Verbesserungen ableiten.

3. Wie integriert ayedo Velero in die eigene Plattform?

In der ayedo Kubernetes Distribution ist Velero als zentraler Backup- und DR-Baustein integriert:

• vordefinierte Backup-Strategien je nach Kritikalität der Workloads,
• standardisierte Anbindung an verschlüsselte, geografisch getrennte Object-Stores,
• Monitoring und Alerting über zentrale Dashboards,
• abgestimmte Prozesse mit datenbankspezifischen Backups (z. B. PostgreSQL, MariaDB, MongoDB).

Damit erhalten Sie eine Lösung, die sowohl technisch robust als auch regulatorisch anschlussfähig ist – ohne dass Ihr Team Velero im Detail neu erfinden muss.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Die regulatorischen Anforderungen rund um GDPR, NIS‑2 und DORA sind bewusst technologieoffen formuliert. Das schafft Spielraum – aber auch Verantwortung. Die zentrale Herausforderung ist nicht, „Velero zu installieren“, sondern ein kohärentes, überprüfbares Backup- und DR-Modell zu etablieren, das:

• zu Ihrer Geschäftsarchitektur passt,
• die richtigen RPO/RTO-Ziele definiert,
• Offsite-Storage, Verschlüsselung und Immutability berücksichtigt,
• und regelmäßig in der Praxis erprobt wird.

Hier setzt ayedo an:

• Unsere Kubernetes-Distribution bringt Velero als integralen Teil der Plattform mit – inklusive Best-Practice-Konfigurationen für automatisierte Backups, Offsite-Storage und Monitoring.
• Wir unterstützen bei der Modellierung von RPO/RTO entlang Ihrer Geschäftsprozesse und regulatorischen Vorgaben, statt nur auf Infrastrukturkennzahlen zu schauen.
• Gemeinsam mit Ihren Teams entwickeln wir Runbooks für Restore und Disaster Recovery, die technisch umsetzbar, auditierbar und für Nicht-Techniker verständlich sind.
• Auf Wunsch begleiten wir DR-Übungen, dokumentieren Ergebnisse und leiten Optimierungen ab – ein wichtiger Baustein, um gegenüber Aufsichtsbehörden Operational Resilience nachweisen zu können.

Wenn Sie Ihre Backup- und Disaster-Recovery-Strategie auf eine solide, compliance-fähige Basis stellen wollen, ohne Ihr Engineering-Team mit Ad-hoc-Lösungen zu überlasten, ist ein strukturierter Ansatz entscheidend. Ein guter nächster Schritt ist ein gemeinsamer Blick auf Ihre aktuelle Architektur, Ihre regulatorischen Verpflichtungen und Ihre Zielsetzung.

Den Einstieg erleichtert unser Backup Strategy Guide.