Velero Kubernetes Backup and Restore: How It Works

A Kubernetes cluster has two kinds of state: the API objects in etcd and the data inside persistent volumes. Velero backs up both, and it does so through the API rather than by copying etcd, which makes it usable for namespace-level migrations as well as disaster recovery. Understanding the CRDs it creates - Backup, Schedule, Restore - is what turns "we have backups" into "we have tested restores".

How the pieces fit

Velero runs as a deployment in the cluster with a CRD per operation. Each operation is a custom resource stored in etcd, and the actual backup tarballs live in object storage. Velero treats object storage as the source of truth: it continuously reconciles the Kubernetes API against the bucket. A backup file present in the bucket with no matching Backup object is synchronised into the cluster, and a Backup object whose tarball has disappeared is deleted from Kubernetes. That reconciliation is exactly what makes cluster migration possible - the new cluster can discover backups it never created.

On-demand and scheduled backups

velero install --provider aws --bucket my-velero-backups \
  --backup-location-config region=eu-west-1 \
  --snapshot-location-config region=eu-west-1

velero backup create app-daily --include-namespaces app --ttl 720h
velero backup describe app-daily --details
velero backup logs app-daily

velero schedule create daily-app --schedule "0 2 * * *" --ttl 720h --include-namespaces app

Backups created by a schedule are named <schedule name>-<timestamp>, with the timestamp formatted as YYYYMMDDhhmmss - which makes them easy to sort and easy to reference from scripts. The --ttl flag sets expiry: when Velero notices an expired Backup resource, it removes the object-storage data and the resource.

Restores

velero restore create --from-backup app-daily
velero restore create --from-backup app-daily --namespace-mappings app:app-test
velero restore create --from-backup app-daily --existing-resource-policy=update
velero restore describe app-daily-20260917020000 --details

By default Velero performs a non-destructive restore: if a resource from the backup already exists in the target cluster, it is skipped rather than overwritten. That is the right default for "get my namespace back" and the wrong one for "make the cluster look exactly like the backup", which is why --existing-resource-policy=update exists. Namespace remapping restores the same objects under different namespaces - the standard technique for validating a restore without disturbing production, or for running a point-in-time copy alongside live data.

Restored objects carry the label velero.io/restore-name=<restore name>, which makes it trivial to find and delete the output of a test restore later.

Backup storage locations and safety

A backup storage location is created read-write. During a restore you can put it in read-only mode, which disables backup creation and deletion for that location - useful when restoring from a bucket you must not modify, and useful as a control during an incident so that nobody "cleans up" the evidence.

Operational practice

• Back up by namespace and by label selector, and keep the selection definitions in Git next to the workloads.
• Use pre/post backup hooks for quiescing stateful applications (database flush, application pause) and to avoid application-inconsistent volume data.
• Run a restore drill into a throwaway namespace on a schedule. A backup that has never been restored is a hypothesis.
• Watch the Backup object status and expiry: a failed backup is silent unless you alert on it, and TTL deletion is irreversible.
• Remember that API versions matter - the target cluster must serve the API group/version used when the backup was taken for the restore to succeed.

Related: Kubernetes Gateway API vs Ingress migration, Kubernetes CNI comparison, and NetworkPolicy default-deny patterns.

原文链接：https://velero.io/docs/v1.18/how-velero-works