Table of Contents
By Khimananda Oli | Last reviewed: August 2026
Cluster state is ephemeral, but business data cannot be. When a misconfigured Helm upgrade wipes a namespace or a node failure corrupts persistent volumes, you need a verified recovery path immediately. Implementing Velero: Backup and Restore Kubernetes provides that safety net by capturing both API resources and volume data into object storage. This guide covers the production-grade configuration required to make your cluster truly resilient.
How do you install Velero for Kubernetes backup?
Installation requires two components: the CLI on your workstation and the server-side controller in the cluster. Before running any commands, verify you have access to an S3-compatible bucket (AWS S3, MinIO, Ceph RGW, or Cloudflare R2). For teams managing Kubernetes persistent volumes and storage, ensuring your storage class supports CSI snapshots is critical for efficient backups.
Create the credentials secret
Velero needs programmatic access to your object storage. Create a file named credentials-velero with your cloud provider keys. Never commit this file to version control.
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYInstall the server components
Use the CLI to deploy Velero into the velero namespace. This command configures the backup location, enables CSI support, and sets up the node agent for filesystem-level backups when snapshots are unavailable.
velero install \
--provider aws \
--plugins velero/velero-plugin-for-aws:v1.10.0 \
--bucket my-k8s-backups \
--secret-file ./credentials-velero \
--backup-location-config region=us-east-1,s3ForcePathStyle=true,s3Url=https://s3.us-east-1.amazonaws.com \
--use-node-agent \
--default-volumes-to-fs-backup \
--features=EnableCSIVerify the deployment status. All pods in the velero namespace must reach Running state before attempting backups. If the server pod crashes repeatedly, check the logs for IAM permission errors or incorrect bucket endpoints.
How does Velero handle persistent volume backups?
Backing up YAML manifests is trivial; preserving stateful data is where most failures occur. Velero offers two distinct mechanisms for handling Persistent Volumes (PVs), and choosing the wrong one leads to either excessive costs or unacceptably long recovery times.
CSI snapshots vs. filesystem backups
Understanding this trade-off prevents operational surprises during recovery drills.
| Feature | CSI Snapshots | Filesystem (Kopia/Restic) |
|---|---|---|
| Speed | Near-instant (metadata only) | Proportional to data size |
| Storage Location | Cloud provider block storage | S3/Object storage bucket |
| Cross-cloud Restore | No (vendor locked) | Yes (fully portable) |
| Prerequisites | CSI driver + SnapshotClass | Node agent DaemonSet |
| Cost Impact | Snapshot storage fees apply | Only object storage costs |
In practice, I recommend a hybrid approach. Use CSI snapshots for large databases on managed cloud infrastructure where restore speed matters most. Use filesystem backups for smaller stateful sets, cross-region DR scenarios, or on-prem clusters lacking native snapshot APIs. Always validate that your Kubernetes secrets management strategy accounts for encrypted volume data during these transfers.
How do you automate scheduled backups and retention?
Manual backups fail because humans forget. Production clusters require declarative schedules defined as Kubernetes resources. This ensures backup policies survive cluster upgrades and operator turnover.
Define a backup schedule
Create a Schedule resource using cron syntax. This example runs daily at 2 AM UTC, retains backups for 30 days, and includes all namespaces except kube-system.
apiVersion: velero.io/v1
kind: Schedule
metadata:
name: daily-cluster-backup
namespace: velero
spec:
schedule: "0 2 * * *"
template:
ttl: 720h0m0s
excludedNamespaces:
- kube-system
- velero
includeClusterResources: true
storageLocation: default
volumeSnapshotLocations:
- defaultMonitor backup health
A scheduled backup that silently fails is worse than no backup at all. Integrate Velero metrics into your existing observability stack. If you are already running Prometheus and Grafana monitoring, enable the Velero metrics endpoint and import the official dashboard. Alert on velero_backup_last_status != 1 to catch failures immediately.
- TTL enforcement: Verify old backups are actually deleted to prevent runaway storage costs.
- Partial failures: Investigate warnings in backup logs; they often indicate RBAC gaps or missing CRDs.
- Duration trends: Rising backup times signal storage performance degradation or network bottlenecks.
How do you test and execute a Kubernetes restore?
An untested backup is merely a hope. You must regularly validate that your Velero: Backup and Restore Kubernetes pipeline actually recovers functional workloads. Testing reveals hidden dependencies, missing ConfigMaps, and broken PVC bindings before a real emergency strikes.
Execute a targeted restore
Full cluster restores are rare. Usually, you need to recover a specific namespace after an accidental deletion. Map the source namespace to a new target to avoid conflicts with existing resources during testing.
velero restore create staging-db-restore \
--from-backup daily-cluster-backup-20260814 \
--include-namespaces production-db \
--namespace-mappings production-db:staging-db-restored \
--waitValidate data integrity
Pod readiness probes passing does not guarantee data correctness. After the restore completes:
- Check PVC binding status with
kubectl get pvc -n staging-db-restored. - Exec into database pods and verify record counts match pre-backup baselines.
- Review application logs for connection errors or missing configuration.
- Delete the test namespace once validation succeeds to free resources.
Document every restore test. Note the duration, any manual interventions required, and discrepancies found. This runbook becomes invaluable during actual incidents when stress levels are high and cognitive load is maxed out.
Making Velero: Backup and Restore Kubernetes Production-Ready
Deploying Velero is straightforward; keeping it reliable requires discipline. Treat your backup infrastructure with the same rigor as your primary workloads. Automate schedule creation via GitOps, monitor backup success rates alongside your four golden signals, and conduct quarterly restore drills. Security matters too—encrypt backups at rest, restrict S3 access with least-privilege IAM policies, and audit restore operations. If your team lacks confidence in executing these steps or needs help designing a compliant DR strategy, reach out to discuss your infrastructure requirements. A tested backup is the only backup that counts.
