Cloud Parts

Velero

Backs up a Kubernetes cluster’s objects and persistent volumes to object storage, and restores them into the same cluster or a new one.

Type
Open source
Made by
Cloud Native Computing Foundation
License
Apache 2.0
Facts checked
6 October 2026

What it is

Velero runs inside a Kubernetes cluster as a server deployment, driven by a velero command-line tool. Every backup, schedule and restore is itself a Kubernetes custom resource that Velero’s controllers act on. A backup asks the Kubernetes API, not etcd, for the objects you picked by namespace, resource type or label, and uploads them as a tarball to object storage: Amazon S3 or an S3-compatible store such as MinIO, Google Cloud Storage, or Azure Blob Storage. Working through the API is what lets it run on managed Kubernetes services, where you usually can’t reach etcd at all.

Persistent volumes are copied one of three ways: a cloud disk snapshot (such as EBS) through a provider plugin; a CSI snapshot, which the CSI snapshot data mover can then copy off the storage system into the backup location; or file-system backup, where a node agent reads files from the running pod’s volume and uploads them with Kopia. Velero treats the bucket as the source of truth, so a fresh cluster pointed at it sees every backup and can restore from it, with namespaces renamed if you like. That makes it the usual tool for moving workloads between clusters as well as for disaster recovery.

Why teams pick it

  • Works through the Kubernetes API, so you back up exactly the namespaces or labels you choose, even on managed clusters without etcd access
  • Captures configuration and volume data together, with pre- and post-backup hooks to make a database flush to disk first
  • Restores into another cluster, with namespace remapping, so one tool covers disaster recovery and migration
  • Plugins for AWS, Google Cloud, Azure and S3-compatible stores, plus any CSI driver that supports volume snapshots

Watch out for

  • Backups aren’t atomic: objects created or edited during a backup can be missed, and file-system backup reads live files, so it’s less consistent than a snapshot
  • File-system backup needs node-agent pods running as root, privileged in some environments, and doesn’t support hostPath volumes
  • Not a database tool: for point-in-time recovery you still archive the database’s own log, for example with WAL-G or pgBackRest
  • restic is being retired: since 1.17 it can only restore old backups, and from 1.19 it can’t restore them either

Alternatives

What all backup & restore have in common →

How it fits with other technologies

Install with the AWS plugin, back up a namespace nightly, restore it under a new name · bash

velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.14.0 \
  --bucket cluster-backups \
  --backup-location-config region=eu-west-1 \
  --snapshot-location-config region=eu-west-1 \
  --secret-file ./credentials-velero

# back up the shop namespace at 03:00 every night, keep each backup 30 days
velero schedule create shop-nightly --schedule="0 3 * * *" \
  --include-namespaces shop --ttl 720h0m0s

# restore the latest backup from that schedule into a new namespace
velero restore create --from-schedule shop-nightly \
  --namespace-mappings shop:shop-restored

See it in a real stack

No architecture uses Velero yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2017–2026

Kubernetes keeps all of a cluster’s state in etcd, and as Heptio’s customers moved Kubernetes into production they tried to recover clusters from copies of etcd, “with varied success”, as the company put it. Heptio, founded by Joe Beda and Craig McLuckie, released Ark on August 3, 2017, alongside the diagnostics tool Sonobuoy: it backed up cluster objects and snapshotted volumes so a whole cluster could be put back as it was.

VMware announced in November 2018 that it would buy Heptio and closed the deal on December 12. In February 2019, with version 0.11, Ark was renamed Velero; 1.0 followed in May. Velero 1.2 moved the AWS, Azure and Google Cloud plugins out of the main code, and 1.10 (2022) added Kopia for file-system backup beside restic, which is now being retired.

After Broadcom bought VMware, it contributed Velero to the Cloud Native Computing Foundation. Its acceptance as a Sandbox project was announced at KubeCon Europe 2026 in Amsterdam, and the code now lives in the velero-io GitHub organisation, with maintainers from Broadcom, Red Hat and Microsoft.

Why it’s built this way

Back up through the Kubernetes API, not etcd
Going through the API lets a backup pick namespaces, types or labels, works on managed clusters that hide etcd, and includes resources from aggregated API servers that live in a separate etcd.
Object storage is the source of truth
Velero syncs any backup it finds in the bucket into the cluster. A brand-new cluster pointed at the same bucket can restore everything, which is what makes migration work.
Plugins outside the core
Keeping every provider in-tree didn’t scale as more storage vendors wanted support, so from 1.2 object-store and volume-snapshot plugins, even the original AWS, Azure and Google Cloud ones, install separately.
Every operation is a Kubernetes resource
Backups, schedules and restores are custom resources handled by controllers, so they can be created, watched and audited like anything else in the cluster.

Timeline

  1. 2017

    Heptio releases Ark on August 3

  2. 2018

    VMware completes its acquisition of Heptio in December

  3. 2019

    Renamed Velero in 0.11 (February); 1.0 in May; moves to VMware’s Tanzu GitHub organisation

  4. 2022

    Velero 1.10 adds Kopia for file-system backup

  5. 2024

    Velero 1.14 merges the CSI plugin into the main project

  6. 2026

    Accepted into the CNCF Sandbox; Velero 1.18 adds concurrent backups

Sources11 · facts checked 6 October 2026

Improve this page on GitHub