Learn Velero - Restore & Selective Restore

#Introduction

In episode 4 you made your first backup and know exactly what it contains. Now we test its real value: restore. The golden rule to hold from now on: a backup can only be considered successful after it has been restored and verified. Never postpone a restore test until a disaster actually happens — that's a lesson repeated throughout this series.

Think of a backup as a family photo stored in the cloud, and restore as reprinting that photo. The photo can be stored beautifully, but if the print comes out blurry (or fails entirely), it's useless. This episode makes sure you can reprint at full quality — even with minor modifications.

#Full Restore

#Deleting the Application First

For an honest recovery simulation, destroy what's already there first:

kubectl delete ns app
kubectl get ns app

The namespace is gone — all resources, including the PVC and its data, are deleted too. Now restore:

velero restore create --from-backup my-backup
velero restore get

When the restore status is Completed, verify:

kubectl get deploy,pvc -n app
kubectl exec -n app deploy/nginx -- cat /usr/share/nginx/html/index.html

index.html contains hello velero — which means both the manifest AND the volume data were recovered. This is an important moment: if only the manifest comes back (empty data), the volume layer of your backup is the problem.

#Why Restore Isn't Exactly "Copy-paste"

Velero doesn't copy resources raw. It applies transformations so the result is valid: removing fields that only matter at runtime (like status), updating UID/owner references, and repopulating service clusterIP. This is why a restore produces an application that works, not just an identical YAML.

#Restoring into a Different Namespace

The most common case: recovering prod data into staging for testing, without touching prod. Use namespace mapping:

velero restore create --from-backup my-backup \
  --namespace-mappings app:app-staging

All resources that were in the app namespace are now created in app-staging, including the PVC — Velero creates a new PVC with the same name in the target namespace and restores its data.

kubectl get deploy,pvc -n app-staging

#Selective Restore

#By Resource

You don't always need to restore everything. For example, if only a ConfigMap was accidentally deleted:

velero restore create restore-cfg --from-backup my-backup \
  --include-resources configmap,secret

#By Namespace

velero restore create restore-partial --from-backup my-backup \
  --include-namespaces app

#By Label Selector

Restore only resources that carry a specific label:

velero restore create restore-frontend --from-backup my-backup \
  --selector app=nginx

All three can be combined, for example "restore Deployments and ConfigMaps labeled app=nginx, only from the app namespace".

#Restore Logs and Verification

A restore with Completed status doesn't guarantee every resource succeeded. Always check the logs:

velero restore describe restore-frontend --details
velero restore logs restore-frontend

The logs show which resources were restored, modified, or skipped — plus the reason (e.g. "already exists" or "storage class not found").

#Closing

Key takeaways:

• Full restore: velero restore create --from-backup <name>; verify manifests + volume data.
• Restore is not raw copy-paste — Velero modifies resources so they're valid and working.
• --namespace-mappings prod:staging recovers into a different namespace for testing/DR.
• Selective restore via --include-resources, --include-namespaces, and --selector.
• Always read velero restore describe --details and velero restore logs after a restore.

In episode 6 next, we'll create automatic and scheduled backups: velero schedule create with cron expressions, TTL settings for auto-expiry, and the fundamental differences between a schedule and a manual backup.