Velero

What is Velero?

Velero backs up Kubernetes cluster resources and persistent volumes, and restores them into the same or a different cluster. It is the accepted answer to disaster recovery once workloads live in Kubernetes.

Best for

Cluster-level backup and migration for Kubernetes

Why choose Velero

Velero is the accepted answer to disaster recovery for Kubernetes, and the reason is that cluster state is not just the persistent volumes. Velero backs up the API objects — deployments, services, config maps, secrets, custom resources — alongside the volume data, and restores them together into the same cluster or a different one. That makes it useful for migration as well as recovery: standing up a cluster in a new location and point-in-time restoring the previous one is a supported workflow rather than a manual reconstruction. It supports scheduled backups, retention, selective inclusion and exclusion by namespace or resource type, and can hook into the application's own logic around snapshotting so stateful services are captured consistently.

Replaces

• Veeam Kasten
• CloudCasa
• Trilio

Key features

• Backs up namespaced and cluster-scoped resources
• Volume snapshots or file-system backups
• Scheduled backups with retention
• Restore and cluster migration

What to watch out for

Its scope is Kubernetes, which makes it exactly wrong for anything outside a cluster. Volume backups depend on the storage provider supporting snapshots or on a file-system backup mechanism, and the behaviour differs substantially between providers — a setup that works on one cluster may silently skip data on another. Restore is not instantaneous, and restoring into a cluster whose resources already exist produces conflicts that need resolving. CSI snapshotting requires installing the right CRDs and a compatible driver before it will work at all. The boundary between what Velero captures and what lives outside the cluster, such as external databases or object storage, is easy to misjudge, leaving a restore that looks complete but is not.

How to deploy

• Install the CLI and server components
• Configure a backup storage location
• Test a restore into a scratch namespace

Getting started

Deploy it with an object storage destination first, because the backup location is the dependency everything else rests on. Confirm the storage provider supports volume snapshots, or choose the file-system backup option deliberately, and verify with a test namespace that data is actually captured rather than assumed. Back up one non-critical namespace, then restore it into a different namespace and compare resources. Add hooks for stateful applications so their data is quiesced during the snapshot. Schedule backups with retention, and once a quarter restore something real rather than trusting the schedule's green checkmarks.

Typical setup

Deployed into the cluster with an object storage destination configured first, because the backup location is the dependency everything else rests on. The storage provider's volume snapshot capability is confirmed, or the file-system backup path is chosen deliberately, and a test namespace proves that data is actually captured rather than assumed. One non-critical namespace has been backed up and restored into a different namespace with resources compared. Hooks quiesce stateful applications around snapshots, schedules and retention are configured, and a real restore is exercised periodically rather than inferred from green checkmarks.

Who should look elsewhere

Do not use it if you do not run Kubernetes, since it does nothing outside a cluster. Avoid it as your only backup for data that lives outside the cluster — external databases and object stores need their own plan, and Velero's coverage stops at the boundary. And if your storage provider cannot snapshot volumes and your data is large, the file-system backup path may be slow enough that you should reconsider the storage layer rather than the backup tool.

Project health

• GitHub stars: 10,320
• Last code push: 2026-10-01
• Open issues: 794
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.