Velero backs up cluster objects and persistent volumes
Velero has two main pieces: a command-line client and a server inside Kubernetes. The server records selected cluster resources and can protect persistent-volume data through the mechanisms supported by the deployment. Backups can support disaster recovery, workload migration, or a copy of production resources for development. That scope is broader than copying files from a node because Kubernetes objects, namespaces, labels, storage locations, and restore behavior all participate.
The breadth comes with an important boundary. A completed cluster backup does not automatically guarantee an application-consistent database. Databases may need hooks, quiescing, transaction-aware dumps, or their own replication and recovery process. Velero can preserve the objects and volume content it is configured to capture, but the operator still defines what a recoverable application means. For stateful workloads, that definition should be written before the first schedule is created.
Version 1.18 documents Kubernetes 1.18 through current releases
The README's compatibility table says Velero 1.18 is expected to work with Kubernetes 1.18 through the latest release, with explicit tests listed for Kubernetes 1.33.7, 1.34.1, and 1.35.0. Maintainers also say they cannot exercise every combination and recommend testing versions outside the recorded matrix. Release qualification includes restoring backups from the previous 2 minor Velero releases. This is useful evidence, though it does not cover every CSI driver, object store, admission policy, or workload.
A real installation joins more moving parts than the overview suggests. The server needs cluster permissions and custom resources. Backup data needs an object-storage location and credentials. Cloud volume snapshots rely on provider plugins, while file-system backup and CSI data movement introduce node agents, repositories, and storage-class behavior. The exact choice affects cost, portability, and restore speed. A proof of concept should use the same provider and volume path planned for production.
What happened when we ran it
Our sandbox cloned commit d2241ad and installed 672 Go packages in 81 seconds. The checkout contained 3,821 files, about 262,654 lines of source, and occupied 66.2 MB before dependencies. The build succeeded in 233 seconds. The repository had 18 CI workflow files, a Dockerfile, and a tests directory, which is the clearest engineering footprint among the projects in this batch.
The Go test step failed with exit code 1 after 217 seconds. Our harness counted 59 passed and 6 failed out of 65. The supplied tail shows several utility packages with no test files, successful kibishii and velero utility packages, and then a final FAIL. It does not include the failing package names or error messages, so assigning a cause would be guesswork. The only safe conclusion is that the full discovered suite did not pass in our fresh Go 1.24 Debian container.
Those results cover source installation, compilation, and repository tests. We did not create a Kubernetes cluster, connect object storage, take a volume snapshot, or restore an application. A 233-second build proves that the code compiled at the measured commit. It says nothing about whether a backup is usable after a cluster loss. That answer requires an end-to-end restore with stored credentials, plugins, and target infrastructure.
A backup is useful only after an isolated restore succeeds
Velero makes scheduled backups easy enough that teams can mistake job completion for recovery readiness. A better acceptance test starts with a disposable namespace containing ordinary objects and a stateful workload, backs it up, removes or isolates the source, and restores into a clean target. Check resource ownership, secrets, services, persistent data, hooks, and application-level reads. Repeat the test after Kubernetes, CSI, object-store, or Velero upgrades.
Storage failure deserves its own runbook. Issue #10398 describes a Velero 1.17.1 deployment on MinIO where the store reached capacity. According to the reporter, backup finalization kept retrying because it could not write status, and deleting an older backup also stalled because completion required another write. That is one environment and an open report. It identifies a practical safeguard: monitor capacity outside Velero and keep a storage-native deletion or expansion procedure that does not depend on the backup controller.
Provider behavior can decide whether a restore is portable
Object stores that speak an S3-like API are not identical. Issue #10400 reports that Dell EMC ECS rejected uploads from the AWS plugin in an air-gapped setup even though listing and AWS CLI uploads worked. The reporter traced a difference in the SDK request and could not solve it through several configuration changes. This does not indict every compatible store. It means the words "S3-compatible" should trigger a write, list, delete, backup, and restore test against the exact appliance version.
Persistent volumes add a second compatibility layer. CSI snapshots can be fast within a provider, while moving snapshot data to object storage may improve recovery independence at extra time and capacity cost. File-system backup behaves differently again. Pick according to the disaster being covered: deleted namespace, failed cluster, lost storage system, or migration to another provider. A snapshot left only inside the failed storage domain is not a complete answer to every one of those events.
Release activity is high, and the support surface is large
GitHub showed 10,254 stars, 825 open issues and pull requests, and a last push on August 26, 2026. A search separating issues from pull requests returned 650 open issues. Latest release v1.18.2 was published June 26 and fixed a namespace-listing performance regression plus two backup-cleanup defects. The activity and 18 workflow files indicate an actively maintained project, while the open queue reflects the number of storage, cloud, and Kubernetes combinations it serves.
Velero is a sensible default shortlist for Kubernetes disaster recovery because it handles cluster resources and volume workflows in one project, has versioned documentation, and supports migration as well as same-cluster restore. Our failed 65-result suite prevents a clean bill of health for the measured commit. More importantly, no source test substitutes for proving that your bucket, plugin, CSI driver, credentials, retention policy, and applications can recover together under pressure.