A disk snapshot backs up a volume’s contents. It backs up neither your Deployment definitions, nor your Secrets, nor your ConfigMaps, nor the full structure of what’s running on the cluster. Losing an entire cluster (a catastrophic configuration error, a hardware failure on the infrastructure hosting it) with no state backup leaves a pile of intact data volumes and no simple way to rebuild what was using them.

What Velero actually backs up

Velero captures two distinct things in a single operation: Kubernetes resource definitions (exported as YAML from the API server) and, optionally, a snapshot of associated volumes through the storage provider’s native integration.

# Full namespace backup: resources + associated volumes
velero backup create prod-backup \
  --include-namespaces production \
  --snapshot-volumes

This dual capture answers a question data replication alone never asks: if the entire cluster disappears, how do you recreate not just the data, but the exact structure (labels, annotations, relationships between objects) that made it all work together?

A backup program, not a one-off backup

A manual backup run once only protects the moment it was taken. Velero is scheduled through a Schedule, the equivalent of a CronJob for backups:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces: ["production"]
    ttl: "720h0m0s"

The ttl (retention period) deserves particular attention: retention too short eliminates the backup you would have needed before the problem was even detected; retention too long accumulates a silent storage cost that grows indefinitely without ever being reviewed.

Tested restore, or a backup that protects nothing

A backup that’s never been restored is a hypothesis, not a guarantee. The export format can be corrupted, a critical resource can be mistakenly excluded by too-broad a filter, a required CustomResourceDefinition can be missing on the destination cluster. Periodically restoring a backup to a test cluster, even a minimal one, is the only way to know whether the backup actually protects what it’s supposed to protect:

# Restoring to a different cluster: the real test of a backup
velero restore create --from-backup prod-backup

An organization that discovers a backup doesn’t restore correctly almost always finds out at the worst possible moment: during the incident it was supposed to cover.

What Velero doesn’t replace

Velero backs up the cluster’s declared state at a given moment; it doesn’t replace a GitOps source of truth that describes that state continuously and under version control. A cluster driven by GitOps already has, in its Git repository, most of what Velero would export for resources themselves: Velero’s added value then concentrates on what Git never captures, the data itself and runtime state (dynamically generated Secrets, for instance).

Takeaway

A complete Kubernetes cluster has two distinct layers to protect: the data it stores (covered by Longhorn’s replication and backups) and its declared structure (resources, Secrets, relationships between objects), which Velero specifically covers. A backup that’s scheduled but never restored for testing remains an unverified hypothesis. This complete safety net is part of the foundation laid from the start of a Kubernetes migration that takes availability seriously.