Kubernetes Backup with Velero

We install Velero with the appropriate storage plugin — AWS S3, GCP GCS, Azure Blob, or MinIO for on-prem. Backup storage locations and volume snapshot locations are configured with encryption and access controls. Velero runs as a deployment in its own namespace with RBAC restricted to backup operations. The install is reproducible via Helm chart with values committed to your GitOps repository.

We configure scheduled backups at multiple granularities: full cluster backup daily, critical namespaces every 6 hours, and database PVs every hour. Label selectors and namespace inclusion/exclusion lists let you control exactly what gets backed up. TTL settings automatically expire old backups. Each schedule is a Kubernetes resource — version-controlled and auditable.

Velero integrates with your cloud provider's snapshot API (EBS snapshots, GCE persistent disk snapshots) or CSI snapshots for provider-agnostic volume backup. We configure snapshot classes, retention policies, and cross-region snapshot copies for DR. For databases running on PVs, we add pre-backup hooks that run pg_dump or mysqldump inside the pod before the snapshot fires.

The real test of any backup is the restore. We validate Velero restores by spinning up a fresh cluster, running velero restore create from the backup storage, and verifying that all workloads come up healthy. Namespace-level restores let you recover a single microservice without touching the rest of the cluster. We document the exact restore procedure and run quarterly DR drills to keep it current.