I understand why Velero can be useful and fairly straightforward to operate, but I'm not convinced it adds much beyond another system to maintain when running a managed Kubernetes cluster such as EKS, AKS, or GKE.
Assume the cluster hosts both stateless and stateful applications, excluding cases where you run your own database. With Flux or Argo CD, applications can be rebuilt and rolled back from source control. Managed databases such as RDS have their own backup systems, and persistent volumes can be protected with snapshots provided by the cloud platform.
In that setup, what specific problem does Velero solve? Does it make disaster recovery, incident response, migrations, or cluster upgrades meaningfully easier, or are provider snapshots and GitOps generally sufficient?
2 Answers
The main distinction is that a storage snapshot is only one part of a backup. Velero can preserve Kubernetes objects, relationships, namespaces, configuration, and persistent-volume data together, then restore them into the same or a different cluster. That matters when the cluster itself is lost, you need to migrate between environments, or you want a consistent point-in-time recovery rather than rebuilding everything manually from Git and then reconnecting storage.
Velero is not necessarily an either-or replacement for provider backups. Its value is in coordinating the higher-level workflow: selecting exactly what to back up, running pre- and post-backup hooks, handling application quiescing, and restoring related resources in a controlled order. Storage systems and cloud snapshot controllers handle the lower-level data protection, while Velero gives you a portable Kubernetes-aware recovery process.
GitOps can rebuild declared resources, but it may not contain generated objects, cluster-scoped resources, secrets, runtime metadata, or the exact state needed for a fast recovery. Whether that extra layer is worth operating depends on your recovery objectives and how comfortable you are rebuilding those pieces manually.
Provider snapshots can still be perfectly useful backups for the volume data, especially if the storage is independent of the cluster. The difference is that restoring the volume alone does not recreate the Kubernetes resources, access settings, secrets, or application ordering around it.