🗺️ What is Velero?

Velero (formerly Ark) is a CNCF open-source tool for backing up and restoring Kubernetes cluster resources and persistent volumes. It supports disaster recovery, data migration between clusters, and pre-upgrade snapshots.

Velero works by integrating with your cloud provider's object storage (e.g. S3, GCS, Azure Blob) for resource manifests and with volume snapshot APIs for PV data.

🧩 Core Concepts

Key CRDs

CRD	Purpose
Backup	Point-in-time backup — what to include/exclude, TTL, hooks
Restore	Restore from a backup — namespace mapping, label selectors
Schedule	Cron-triggered recurring Backup creation
BackupStorageLocation	Object-store bucket + credentials (multiple supported)
VolumeSnapshotLocation	Where volume snapshots are stored (cloud zone/region)
DownloadRequest	Used internally by CLI to stream backup logs

Backup Approaches

Installing Velero (AWS example)

# Install Velero CLI (macOS)
brew install velero

# Create static credentials file (use IRSA in production)
cat > credentials-velero <<EOF
[default]
aws_access_key_id=AKIAIOSFODNN7EXAMPLE
aws_secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
EOF

# Deploy Velero into the cluster
velero install \
  --provider aws \
  --plugins velero/velero-plugin-for-aws:v1.9.0 \
  --bucket my-velero-backups \
  --secret-file ./credentials-velero \
  --backup-location-config region=us-east-1 \
  --snapshot-location-config region=us-east-1 \
  --use-node-agent

Verify Installation

kubectl get deployment velero -n velero
velero backup-location get
# NAME      PROVIDER   BUCKET/PREFIX         PHASE
# default   aws        my-velero-backups     Available
kubectl get daemonset node-agent -n velero

# NAME PROVIDER BUCKET/PREFIX PHASE # default aws my-velero-backups Available kubectl get daemonset node-agent -n velero

💾 Backups & Restores

Creating a Backup

# Ad-hoc backup of a single namespace
velero backup create my-app-backup \
  --include-namespaces my-app \
  --ttl 720h    # retain for 30 days

# Backup with label selector
velero backup create api-backup \
  --selector app=api \
  --include-namespaces production

# Backup entire cluster (all namespaces)
velero backup create full-cluster-backup

# Check status
velero backup describe my-app-backup
velero backup logs my-app-backup

Backup YAML manifest

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: my-app-backup
  namespace: velero
spec:
  includedNamespaces:
    - my-app
  excludedResources:
    - events
    - events.events.k8s.io
  ttl: 720h0m0s
  storageLocation: default
  volumeSnapshotLocations:
    - default
  hooks:
    resources:
      - name: freeze-db
        includedNamespaces: [my-app]
        labelSelector:
          matchLabels: {app: postgres}
        pre:
          - exec:
              container: postgres
              command: ["/bin/bash", "-c", "psql -c 'CHECKPOINT;'"]
              onError: Fail
              timeout: 30s

Restoring from a Backup

# Restore everything from a backup
velero restore create --from-backup my-app-backup

# Restore to a different namespace
velero restore create \
  --from-backup my-app-backup \
  --namespace-mappings my-app:my-app-restored

# Restore only specific resources
velero restore create \
  --from-backup my-app-backup \
  --include-resources deployments,services,configmaps

# Monitor restore status
velero restore describe my-app-backup-20240101
velero restore logs my-app-backup-20240101

Scheduled Backups

# CLI shorthand
velero schedule create daily-app-backup \
  --schedule="0 2 * * *" \
  --include-namespaces my-app \
  --ttl 168h   # 7 days

# As a YAML manifest
apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-app-backup
  namespace: velero
spec:
  schedule: "0 2 * * *"   # 2 AM daily
  template:
    includedNamespaces:
      - my-app
    ttl: 168h0m0s
    storageLocation: default

Backup Retention Strategy

Schedule	Frequency	TTL	Use case
Hourly	@every 1h	24h	High-change workloads, short-term undo
Daily	0 2 * * *	7d	Standard production namespaces
Weekly	0 3 * * 0	30d	Compliance / long-term retention
Monthly	0 4 1 * *	365d	Regulatory / audit archives

🚚 Cluster Migration

Velero's most powerful use case: move workloads from one cluster to another — across regions, cloud providers, or on-prem to cloud.

Migration Workflow

1. Install Velero on source cluster pointing to shared object storage bucket.
2. Run velero backup create cluster-migration --include-namespaces app1,app2 on source.
3. Verify backup is Completed: velero backup describe cluster-migration.
4. Install Velero on destination cluster pointing to the same object storage bucket (read-only is fine).
5. Run velero restore create --from-backup cluster-migration on destination.
6. Validate workloads, update DNS/load-balancer endpoints, drain source.

# Map storage classes during restore
velero restore create \
  --from-backup cluster-migration \
  --storage-class-name standard=premium-ssd

# Or use a ConfigMap
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: change-storage-class-config
  namespace: velero
  labels:
    velero.io/plugin-config: ""
    velero.io/change-storage-class: RestoreItemAction
data:
  gp2: gp3
  standard: premium-ssd
EOF

Multiple Backup Storage Locations

You can configure secondary BSLs for cross-region redundancy:

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

# Mark a BSL as read-only (for migration destination)
velero backup-location set secondary --access-mode ReadOnly

Production Best Practices

📝 Knowledge Check