Kubernetes backup is more than copying YAML
Velero has survived since 2017 because it treats cluster recovery as two linked jobs. First, it copies Kubernetes resources from the API server into object storage. Second, it protects persistent data through cloud snapshots, CSI snapshots, CSI snapshot data movement, or file-system backup. A controller runs inside the cluster and acts on Backup, Restore, and Schedule custom resources; a local CLI creates and inspects those operations.
This shape works for disaster recovery, cluster migration, and making a development cluster from production state. Backups can include or exclude resources by namespace, type, and label. Restores can remap namespaces, and the default policy is non-destructive: an object already present in the destination is skipped unless the operator chooses an update policy. Object storage is the source of truth, so a fresh cluster can discover stored backup metadata even though the original custom resources are gone.
Those are meaningful capabilities, not merely a YAML export script. They also explain why installing Velero is the beginning of the job rather than the end.
You must choose the right data path
Native or CSI volume snapshots are attractive because they capture storage quickly and more consistently than walking a live file system. Velero's built-in CSI support works with the Kubernetes snapshot APIs, provided the cluster has a v1-capable CSI driver and suitable VolumeSnapshotClass. Cross-cluster restores require the CSI driver name on the destination to match the source. The documentation also warns that not every provider guarantees snapshot durability. A snapshot stored beside the original volume may disappear in the same disaster, so operators must verify the provider's storage design.
Velero can move CSI snapshot data to separate object storage when snapshot locality is unacceptable. For volumes without a snapshot mechanism, File System Backup uses node agents and Kopia. It supports NFS, EFS, Azure Files, emptyDir, and many other mounted volume types. The tradeoff is consistency: files are copied from a live mount at different moments. Databases need backup hooks or their own dump and quiescing procedure if crash consistency is insufficient. Cluster-object backup is not atomic either, so resources changing during collection can land in mismatched states.
File backup has concrete limits. The v1.18 documentation calls it beta, excludes hostPath volumes, and requires a volume to be mounted by a pod. On some platforms the node agent needs privileged access to kubelet paths. It can consume serious CPU, memory, and ephemeral storage, especially with huge file counts or repository caches. Teams should set resources from their own data rather than copy a generic example.
The security and lifecycle details deserve a design review
The sharpest warning is in the file-backup documentation: Velero currently uses a static common encryption key for the repositories it creates, so anyone who can access that backup storage can decrypt the data. Object-store permissions and isolation are therefore part of the encryption boundary. Generate your own repository password before the first backup, because changing it after a repository exists prevents Velero from opening older backups.
Retention needs equal care. A backup TTL defaults to 30 days, and expiration removes the backup object, object-store file, and associated persistent-volume snapshots. The latest v1.18.2 patch fixed a case where Kopia snapshots could leak after backup expiry, along with a VolumeGroupSnapshot cleanup issue and a namespace-listing performance regression. Those fixes show both the detail in Velero's cleanup machinery and the cost of getting it wrong. Monitor deletion failures and storage growth instead of assuming TTL means data disappeared.
Older restic repositories need an explicit exit plan. New restic-path backups are already disabled in versions 1.17 and 1.18, while restore remains available. The documented policy says 1.19 disables that restore path too. An operator with historical restic recovery points cannot upgrade indefinitely and expect them to remain readable through Velero.
Setup is an integration project
Getting the client takes minutes through Homebrew, Chocolatey, or a release archive. Installing the server requires choosing object storage and a matching plugin, placing credentials, and deciding whether volume snapshots, CSI, or node-agent backup will protect each volume. Different object and snapshot providers can be combined, but each adds its own configuration and compatibility matrix. Helm is available for teams that want the deployment managed as code.
A production rollout should include scheduled backups, retention, repository maintenance, resource filters, alerting, and restore hooks. More importantly, it needs a clean-cluster recovery exercise. Velero restores the API group and version recorded in the backup only if that endpoint exists in the destination cluster. Kubernetes upgrades, removed APIs, changed storage classes, and missing CSI drivers can turn a green backup into a failed migration. The project tests restoration from backups made by the previous two minor releases, which is useful but narrower than indefinite compatibility.
Healthy, mature, and carrying a large surface area
The repository was pushed on August 15, 2026, after v1.18.2 shipped on June 26. Recent work covers CSI cleanup, restore timeouts, security dependency reports, object-store behavior, tests, and data-mover scheduling. GitHub's 824 open count combines issues and pull requests, so it is not a count of 824 bugs. It does show the support load created by many Kubernetes versions, storage providers, plugins, and recovery paths.
Community support is best effort for the current and previous minor versions, organized through a weekly maintainer rotation rather than a 24-hour service. The documentation is excellent and versioned, with candid limitations, provider guides, troubleshooting, architecture, performance notes, and upgrade instructions. Velero is mature enough to trust as an engine, but no backup engine can validate your application recovery for you.
For most platform teams building an open-source Kubernetes recovery program, Velero is the right place to start. Its broad provider support and multiple data paths beat assembling independent scripts. The condition is non-negotiable: test full restores regularly, protect the object store as carefully as the cluster, and make database consistency an application decision rather than a checkbox.