I understand why Velero can be useful, but I'm not convinced it adds much beyond another system to operate when running a managed Kubernetes cluster such as EKS, AKS, or GKE. Assume the cluster hosts both stateless and stateful applications, excluding databases that are already managed by a service such as RDS. GitOps tools like Flux or Argo CD can rebuild application resources and support migrations or A/B deployments, while provider-managed volume snapshots can protect persistent data. In that setup, what specific problem does Velero solve? Does it make disaster recovery, incident response, or cluster upgrades meaningfully easier, or is it mostly redundant?
2 Answers
Velero and provider volume snapshots solve different layers of the problem. A snapshot protects the contents of a volume, but Velero can capture and restore Kubernetes objects such as namespaces, deployments, services, config maps, secrets, RBAC rules, and custom resources. It can also coordinate application-aware pre- and post-backup hooks. That makes it possible to restore a usable application environment rather than reconstructing the cluster state manually and hoping the storage snapshots line up.
GitOps is excellent for rebuilding the desired configuration, but it is not necessarily a point-in-time backup of everything that existed in the cluster. It may not include generated resources, manually created objects, secrets, custom-resource state, or the exact relationship between application resources and their persistent volumes. Velero provides a portable backup and restore workflow, including selective restores and storage-backend options. It does not have to replace GitOps or cloud snapshots; it can complement them for disaster recovery and cluster migrations.
Right, snapshots alone are not always a complete backup strategy. They protect storage, while a recovery plan also needs the Kubernetes metadata, ordering, hooks, and a tested way to bring the application back online.

That distinction makes sense, although provider snapshots can still cover the data itself. In that case, Velero seems most useful for the Kubernetes resource definitions and the orchestration around restoring them.