My Public Notepad

Wednesday, 1 July 2026

Introduction to Velero

Velero is an open-source disaster recovery, Kubernetes-native backup, restore and migration tool for Kubernetes. It allows you to back up and restore both your Kubernetes cluster resources and, optionally, the persistent volumes (PVs) that hold application data.

It was originally created by Heptio (the company founded by two of Kubernetes' creators) and is now maintained by VMware and the open-source community.

What does Velero back up?

Velero can back up:

Kubernetes resources (Cluster API objects):

Deployments
StatefulSets
Services
Ingresses
ConfigMaps
Secrets
CRDs
Namespaces
RBAC resources
Custom Resources

They are stored as tarballs in an S3 bucket.

Optionally, it can also back up:

Persistent Volumes (application data)
- via storage snapshots (AWS EBS, Azure Disk, GCP Persistent Disk, etc.)
- or via a file-level backup tool called Node Agent (formerly Restic)

How it works

A typical Velero deployment consists of:


                    +----------------+
                    | Kubernetes API |
                    +--------+-------+
                             |
                        Velero Server
                             |
         +-------------------+-------------------+
         |                                       |
 Metadata Backup                        Volume Backup
         |                                       |
         v                                       v
   Object Storage                    Snapshot or File Backup
   (S3, Azure Blob,                  (EBS, CSI Snapshot,
    GCS, MinIO...)                    Node Agent/Restic)

For example:

Cluster metadata → stored in an S3 bucket
PV data → stored as EBS snapshots or uploaded to object storage

Typical use cases

1. Disaster recovery

Your EKS cluster is accidentally deleted.

With Velero you can:

recreate the cluster
install Velero
restore all workloads
restore persistent data

2. Accidental deletion

Someone runs:


kubectl delete namespace production

Instead of recreating everything manually:


velero restore create \
  --from-backup production-backup

3. Cluster migration

Move workloads from:

EKS → EKS
EKS → AKS
EKS → GKE
On-prem → cloud

Velero restores Kubernetes objects into the new cluster.

4. Scheduled backups

Example:


Every night at 2 AM

↓

Backup namespaces:
- production
- monitoring
- logging

Retention can be configured, for example:


Keep 30 daily backups
Delete older ones automatically

What it does NOT back up

Velero does not automatically back up:

etcd directly
cloud infrastructure (VPCs, Load Balancers, IAM, Security Groups)
managed databases like RDS
container images (they remain in your registry)
external services

Those require separate backup strategies.

Storage providers

Velero supports many object storage backends:

Amazon S3
MinIO
Azure Blob Storage
Google Cloud Storage
OCI Object Storage
many S3-compatible systems

Persistent Volume backup methods

There are two main approaches.

1. CSI snapshots (preferred)

If your storage class supports the Container Storage Interface (CSI) snapshot API:


PVC
 ↓
VolumeSnapshot
 ↓
Cloud snapshot

Advantages:

very fast
incremental (depending on storage backend)
cloud-native
recommended

2. Node Agent (formerly Restic)

If snapshots aren't available:


PVC
 ↓
Read filesystem
 ↓
Compress
 ↓
Upload to object storage

Advantages:

works almost everywhere
storage-independent

Disadvantages:

slower
consumes CPU and network bandwidth

Example architecture in AWS


                 Amazon EKS
                      |
          +-----------+-----------+
          |                       |
     Kubernetes API          Persistent Volumes
          |                       |
      Velero Server         EBS Snapshots
          |
          |
      S3 Bucket
      backups/

Example installation

Install the CLI:


brew install velero

Deploy into an EKS cluster:


velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws \
  --bucket my-backups \
  --backup-location-config region=eu-west-2

Example backup

Back up an entire cluster:


velero backup create full-cluster

Back up a namespace:


velero backup create production \
    --include-namespaces production

Example restore


velero restore create \
    --from-backup full-cluster

Scheduling

Create a nightly backup:


velero schedule create nightly \
    --schedule="0 2 * * *"

When should you use Velero?

Velero is a good fit if you want to:

Recover Kubernetes workloads after accidental deletion or cluster failure.
Back up application manifests and, optionally, persistent data.
Migrate workloads between Kubernetes clusters or cloud providers.
Automate recurring backups with retention policies.
Protect stateful applications running on Kubernetes.

If your applications also depend on external systems (for example, managed databases, message brokers, or cloud resources), Velero should be part of a broader disaster recovery strategy rather than the only backup solution.

Velero vs. etcd backup

Feature	Velero	etcd backup
Kubernetes resources	✅	✅
Persistent volume data	✅	❌
Restore individual namespaces	✅	❌
Restore individual applications	✅	❌
Migrate between clusters	✅	Limited
Cloud agnostic	✅	Mostly
Disaster recovery for applications	✅	Partial

For managed Kubernetes services such as Amazon Elastic Kubernetes Service (EKS), Velero is generally the preferred backup tool because it focuses on application-level recovery rather than restoring the control plane itself. In contrast, direct etcd backups are more common in self-managed Kubernetes clusters where you control the control plane.

Pages