Velero: Backup & Disaster Recovery for DORA and NIS-2

TL;DR

• Velero is a mature open-source tool for backups, migration scenarios, and disaster recovery in Kubernetes environments – making it a central component for any robust compliance architecture.
• Regulatory requirements like GDPR (applicable since 05/25/2018), NIS‑2 (implementation by 10/17/2024), and DORA (effective from 01/17/2025) explicitly demand robust business continuity and recovery concepts – not just backups “somewhere in an S3 bucket.”
• A coherent backup strategy includes automated, policy-based backups, geographically separated and encrypted storage, clear RPO/RTO goals, and regularly practiced restore and disaster recovery processes.
• Velero becomes the operational heart of the DR process in critical scenarios – from the loss of a namespace to a complete cluster failure – linking technical recovery with regulatory-compliant documentation.
• ayedo provides an integrated solution: The ayedo Kubernetes Distribution includes Velero, offsite storage, monitoring, and standardized DR processes as building blocks – including consulting for alignment with GDPR, NIS‑2, and DORA.

Velero Overview: Backup and Migration Engine for Kubernetes

In productive Kubernetes landscapes, a robust backup and disaster recovery concept is no longer optional but a regulatory obligation. Velero has established itself as the de facto standard here.

What Velero Does

Velero addresses three core tasks:

1. Backup of Cluster Resources
   This includes deployments, StatefulSets, services, ConfigMaps, secrets, and all objects in the Kubernetes API server. Velero secures not just “data,” but the complete application state.

2. Backup of Persistent Volumes
   Persistent volumes are backed up via CSI snapshots or file-based backups. This allows complete workloads – including databases – to be consistently restored, supplemented by database-specific procedures where necessary.

3. Migration and Replication of Workloads
   Backups can be restored in other clusters. This is helpful:

   • for DR clusters in a second data center,
   • for cloud migrations,
   • for test restores without impacting production.

Velero typically works with S3-compatible object stores, is cloud-agnostic, and integrates seamlessly into existing platform architectures. In a regulated environment, it becomes a critical component of the entire disaster recovery strategy.

Regulatory Requirements: NIS‑2, DORA, and GDPR in the Backup Context

European regulations explicitly demand more than “we have snapshots somewhere.”

GDPR: Availability and Resilience

GDPR Art. 32 has required since 05/25/2018 an appropriate level of protection for personal data, including protection against “accidental or unlawful destruction or loss.”
Specifically, this means:

• Backups for all systems processing personal data,
• Processes for the timely restoration of availability,
• Documented technical and organizational measures (TOMs),
• Regular review of the effectiveness of these measures.

Velero primarily addresses:

• the technical recovery path,
• the traceability of backups (logs, status),
• the ability to reproducibly conduct restore tests.

NIS‑2: Business Continuity and Backup Management

The NIS‑2 directive (NIS‑2, Directive (EU) 2022/2555) must be transposed into national law by 10/17/2024. It requires “important” and “essential” entities to have:

• Business continuity concepts, including
  • Backup management,
  • Disaster recovery,
  • Crisis communication.
• Measures to ensure availability and recoverability of critical services.

For Kubernetes platforms, this means:

• Defined RPO/RTO goals for all critical workloads,
• Regular and monitored backups,
• Documented DR plans,
• Regular DR exercises.

Velero becomes the operational tool that technically implements these requirements and makes them traceable through monitoring.

DORA: BCP/DR as a Lived Process

The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) comes fully into force on 01/17/2025. It is particularly aimed at financial companies and their IT service providers.

At its core, DORA demands:

• Mature business continuity and disaster recovery plans (BCP/DR),
• Clear responsibilities and escalation paths,
• Regular tests – from simple restores to complex scenario exercises,
• Proof of operational resilience to supervisory authorities.

For Kubernetes environments, this means:

• A documented end-to-end process from failure to recovery,
• Technical tools like Velero that enable standardized, reproducible recovery,
• Metrics and reports that make resilience measurable.

Backup Strategy for Regulated Kubernetes Environments

A tool like Velero only unfolds its effectiveness within a clearly defined strategy. The following elements are essential in regulated environments.

What Needs to Be Backed Up

1. Kubernetes Objects
   All resources that define the state of your applications:

   • Namespaces, deployments, StatefulSets, services, ingress,
   • ConfigMaps, secrets, custom resources (e.g., operators).

2. Persistent Data

   • Volumes on which databases or stateful services run,
   • Files, reports, logs that are regulatory relevant.

3. Cluster Metadata and Configuration

   • Cluster-wide configurations,
   • RBAC roles and bindings,
   • Network policies.

4. Database-Specific Backups
   Velero cannot cover all peculiarities of PostgreSQL, MariaDB, MongoDB, etc., alone. Here, complement with:

   • Database-specific backup tools (e.g., WAL archiving, binary logs),
   • Consistent coordination with Velero backups,
   • Central monitoring of all backup jobs.

Frequency, RPO, and RTO

Regulations require clarity:

• Recovery Point Objective (RPO): How many minutes/hours of data loss are acceptable?
• Recovery Time Objective (RTO): How long may the recovery of critical systems take?

Typical patterns:

• Daily standard backups (RPO ≈ 24 h) for non-critical workloads,
• Multiple daily or hourly backups for critical applications,
• Additional on-demand backups before releases, schema changes, or major platform updates.

Velero allows for multiple schedules per namespace or workload class, supporting finely granular RPO strategies.

Storage Architecture: Offsite, Encrypted, Traceable

For NIS‑2 and GDPR, the choice of backup target environment is crucial:

• Geographically Separated Data Centers
  Primary cluster in DC A, backups in DC B (at least a two-digit kilometer distance).
  For particularly sensitive regulatory setups, an additional third location.

• S3-Compatible, Encrypted Object Storage

  • AES-encrypted buckets,
  • Ideally WORM/immutability features against ransomware,
  • Versioned buckets to catch accidental deletions.

• Network and Rights Design

  • Minimal access to backup storage (least privilege),
  • Strict separation of production and backup credentials,
  • Central logging of all accesses.

Velero can be configured so that all backups are automatically written to this offsite environment – transparent to the workloads.

Monitoring, Alerting, and Governance

A backup that no one knows if it’s running does not meet compliance requirements.

Essential elements:

• Dashboards

  • Overview of successful/failed backups,
  • Volume of backups,
  • Run times and trends.

• Alerting

  • Alerts for failed backups,
  • Alerts for missing backups (e.g., no successful backups in the last 25 hours),
  • Alerts for storage bottlenecks.

• Documented Policies

  • Retention times (daily, weekly, monthly, possibly annual long-term backups),
  • Responsible roles (e.g., “Backup Owner” per critical application),
  • Approval processes for changes to the backup setup.

Velero as a Critical Component for Disaster Recovery

Velero is not a “nice to have” tool but in many architectures the operational core of the disaster recovery process.

Role in Typical DR Scenarios

1. Loss of Individual Namespaces or Applications

   • Granular restores at the namespace or resource level,
   • Quick return to the last consistent state,
   • Minimal impact on other workloads.

2. Data Corruption Due to Application Errors

   • Restoration to an earlier state (e.g., before a faulty release),
   • Combination with database-side point-in-time recovery.

3. Total Loss of a Cluster or Data Center

   • Restoration of workloads in a standby or newly set up cluster,
   • Automated reconstruction of Kubernetes resources from the offsite backup,
   • Step-by-step restoration of critical services by priority.

In all these scenarios, Velero is the tool that turns backups into concrete, operational services.

Interaction with Database Backups

Critical databases require additional mechanisms (e.g., WAL or binary log archiving). The DR process typically looks like this:

• Kubernetes resources (deployments, services, PVC bindings) are restored via Velero.
• The databases themselves rely on their own backups and replication mechanisms.
• Monitoring and governance consider both levels together.

This creates an integrated, auditable picture of resilience.

Practical Example: Disaster Recovery Process for Kubernetes Workloads

What does a realistic DR process look like that addresses GDPR, NIS‑2, and DORA and uses Velero as a core component?

1. Preparation (Pre-DR)

Even before an incident, the following components must be in place:

• Classification of Workloads

  • Critical, highly critical, and less critical applications,
  • Respective RPO/RTO goals and regulatory relevance.

• Standardized Backup Policies

  • Schedules per class (e.g., hourly for highly critical workloads),
  • Defined offsite target,
  • Tested retention rules.

• Technical Basis

  • Velero productively integrated into the cluster,
  • Access to a separate DR cluster or the ability to quickly set one up,
  • Centralized monitoring and alerting.

• Documented Runbooks

  • Step-by-step instructions for restore and DR scenarios,
  • Clearly defined roles and escalation paths.

2. Incident: Detection and Decision

In the event of a serious incident (e.g., ransomware suspicion, storage corruption, DC failure):

1. Incident Detection: Monitoring or security team raises the alarm.
2. Assessment:
   • Extent of the damage,
   • Affected workloads and data,
   • Assessment of whether a restore or a failover to another DC is necessary.
3. Decision: Activation of the DR plan by the responsible body (e.g., IT emergency team).

3. Technical Recovery with Velero

In the DR cluster or newly set up cluster:

1. Provision the Cluster
   • Provide Kubernetes cluster according to the standard configuration,
   • Basic infrastructure setup.