Learn Velero - History, Background & Why You Need It

#Introduction

Your environment is ready from episode 0. Now it's time to understand why Velero exists. Every great technology is born from a real problem, and Velero was born from a very specific one: storing and recovering data in Kubernetes is not as simple as saving files. In episode 1 we trace its history from Heptio, its evolution into a CNCF project, and the concrete reasons this tool is needed in modern Kubernetes workloads.

The questions we will answer: why doesn't Kubernetes itself have a built-in backup feature? What makes backing up K8s different from backing up a regular VM? And why did Velero eventually become the standard solution? These answers matter because they determine when you should use Velero — and when you shouldn't.

#History and Background

#Born at Heptio

Velero was first developed by Heptio — the company founded by Craig McLuckie and Joe Beda, two former Google engineers who also co-founded Kubernetes. It was originally named Ark, then renamed to Velero (from the Italian/Spanish word "velero" for "sail" — a fitting metaphor for journeys and recovery). Heptio was acquired by VMware in 2018, and Velero is now maintained under VMware/Broadcom, but remains open source.

From the start, Velero's philosophy was clear: backups must be portable. Not a tool locked to a single vendor, but a solution that can back up any cluster and store data to any object storage.

#Becoming a CNCF Project

Velero was accepted as a CNCF (Cloud Native Computing Foundation) project and currently holds sandbox status in the CNCF ecosystem. What does this mean for you? A few things:

• Open governance: the roadmap and development direction are decided together with the community, not by a single vendor.
• Plugin ecosystem: many providers (AWS, Azure, GCP, OpenStack) and third-party vendors build official plugins.
• Long-term assurance: a CNCF project is far less likely to simply disappear than a proprietary tool.

#The Standard BaaS Solution for Kubernetes

From there, Velero grew into the standard backup-as-a-service (BaaS) solution for Kubernetes. The name "Velero" is now often used as a generic term for "K8s backup", much like "Kleenex" for tissue. This position didn't come from marketing, but from a precisely targeted architectural design — something we dissect in episode 2.

#Why You Need Velero

#Kubernetes Has No Built-in Backup

This is the most important point: etcd snapshots are not workload backups. Saving an etcd snapshot (the cluster's state database) does restore the cluster "configuration", but it does not restore volume data stored outside etcd. And manual backups with kubectl get -o yaml only capture manifests — data in PVCs and application state are left behind.

Imagine backing up the contents of a filing cabinet index (etcd = table of contents) but forgetting to carry the actual documents (volume = the real files). Restoring from these two things are two completely different operations — and you need both.

#API Resource + Volume Backup

Velero combines both in a single flow. One backup operation produces:

• Resource manifests: Deployment, Service, ConfigMap, Secret, PVC, CRD — all as YAML/JSON.
• Volume data: the contents of persistent volumes via cloud snapshots (EBS/GCP PD/Azure Disk) or file-level backup using restic/kopia.

These two layers make restore selective: you can recover a full application, only manifests, or only specific volume data.

#Selective Restore and Cross-Cluster Migration

Velero doesn't just do "back up everything". You can restore partially — per namespace, per resource, or per label — and even map namespaces (e.g. prod → staging). This unlocks the second most powerful capability: cross-cluster migration. Back up on cluster A, restore on cluster B, without vendor lock-in — as long as both clusters use the same BSL.

#Scheduling and Disaster Recovery

Velero supports schedules (scheduled backups with automatic TTL), so you can build a disaster recovery plan with measurable RPO/RTO: off-site backups to object storage, periodic DR drills, and a restore runbook executable within minutes.

#Position in the K8s Backup Ecosystem

To position Velero, keep in mind the spectrum of Kubernetes backup tools:

• Velero: general-purpose, open source, resource + volume backup, cross-cluster migration.
• Kasten K10 (Veeam): enterprise, full UI and policies built on a Velero-like foundation.
• Stash (AppsCode): script-based (restic) backup per workload.
• CloudNativePG/PGO: PostgreSQL-specific backup inside Kubernetes.
• etcd snapshot: cluster state backup, not workload backup.

We compare them in detail in episode 22. What you need to remember now: Velero is the right entry point because it is open source, mature, and covers general backup needs.

#Closing

Key takeaways:

• Velero was born at Heptio (originally named Ark), now under VMware/Broadcom but still open source.
• A CNCF project (sandbox) with open governance and a rich plugin ecosystem.
• Kubernetes has no built-in backup: etcd snapshots are not workload backups, and manifests without volume data are incomplete.
• Velero combines API resource + volume backup (cloud snapshot or restic/kopia) in one flow.
• Selective restore, namespace mapping, cross-cluster migration, scheduling, and DR without vendor lock-in.

In episode 2 next, we will dissect Velero's core concepts and main architecture — how the velero server runs as a deployment in the cluster, the role of the velero CLI, and the functions of the BackupStorageLocation (BSL) and VolumeSnapshotLocation (VSL) CRDs that form the backbone of this entire series.