Velero Backup Internals

Interactive visualization of how Velero processes a Backup — from CR creation to completion.
Built from reading the source at vmware-tanzu/velero@b74f8c9.

What is Velero?

Velero is a backup and disaster recovery tool for Kubernetes clusters. It backs up Kubernetes resources (Deployments, ConfigMaps, Secrets, CRDs, etc.) and persistent volume data, stores them in an object storage bucket (S3, GCS, Azure Blob), and can restore them to the same or a different cluster.

When you run velero backup create my-backup, a Backup custom resource is created in the cluster. What happens next involves four independent controllers, multiple volume protection strategies, and several concurrent processes — all coordinated through phase transitions on the Backup CR's status field.

These visualizations trace that entire flow through the Velero source code.

Controller pattern

Velero uses the Kubernetes controller pattern. Each controller watches the Backup CR for specific phases and acts independently. They communicate by writing phases to the CR — no direct calls between controllers.

Volume protection

Volumes can be protected via Kopia file-system backup (copies files), CSI VolumeSnapshots (in-cluster or moved to BSL via data mover), or native cloud snapshots (AWS EBS, GCP PD, Azure Disk).

Async operations

Some operations (like CSI data movers) are asynchronous — they continue running after the backup engine finishes. A separate controller polls until they complete.

Concurrency

Multiple things run in parallel: a worker pool processes item blocks, node-agents on different nodes run Kopia simultaneously, and a progress goroutine ticks every second.

▦▦▦▦

Controller Flow

Swim-lane diagram of the four controllers. See how a Backup CR jumps between them via phase transitions. Run simulations for happy path, failures, and each volume strategy.

Swim lanes + simulation
◥◤

Volume Decision Tree

Answer questions about your config (CSI enabled? SnapshotMoveData? annotations?) and walk through the exact code path that determines how each volume is protected.

Interactive wizard
▶▮▮

Timeline

Gantt chart showing what runs in parallel during a backup. Dependency arrows show what blocks on what. Annotations explain handoffs and concurrent behavior.

Gantt + dependencies
⇄⇄

Data Mover Paths

Compare how data moves from cluster to storage. CSI + Kopia scans the full volume; KubeVirt Datamover uses CBT to move only changed blocks. See both backup and restore flows.

Interactive comparison
📚

Kind Glossary

Reference for every CRD and Kubernetes kind involved in backup. Includes concepts like Kopia, CBT, qcow2, CSI, and STS with links to learn more.

Searchable reference

What these visualizations cover

+Queue controller — concurrency, NS conflicts, FIFO ordering
+Backup controller — validation, engine, phase determination
+Operations controller — async plugin operation polling
+Finalizer controller — async result processing, terminal phase
+Kopia FSB — PodVolumeBackup, node-agent, opt-in/opt-out
+CSI snapshots — VolumeSnapshot, SnapshotMoveData, DataUpload
+Native snapshots — VolumeSnapshotter plugins (AWS/GCP/Azure)
+Volume policies — ResourcePolicy ConfigMap, match actions
+Hooks — pre/post backup hooks on pods per item block
+Concurrency model — worker pool, progress goroutine, parallel PVBs
+Data mover paths — CSI + Kopia vs KubeVirt Datamover comparison
+KubeVirt CBT — Changed Block Tracking, incremental qcow2, restore chain