Restore a backup
This guide restores one namespace from a backup taken by the
velero module, on aws. It is an operator’s task: a
Restore can rewrite any namespace.
What you need: the velero CLI 1.18, a kubeconfig with cluster-admin
rights, and the module’s server running
(kubectl -n velero get deploy velero shows it available).
Velero never overwrites an object that exists: it skips it. The namespace must be empty first, and stay empty until the restore.
1. Find the backup
Section titled “1. Find the backup”Backups are named after their Schedule, velero-<frequency>-<retention>,
with a timestamp:
velero schedule getvelero backup get --selector velero.io/schedule-name=velero-daily-7dCheck the one you pick is Completed and holds your namespace and its
volumes:
velero backup describe <backup> --details2. Suspend your GitOps sync
Section titled “2. Suspend your GitOps sync”Otherwise Argo CD recreates an empty claim, and Velero skips the one it should restore:
argocd app set <app> --sync-policy none3. Delete the namespace
Section titled “3. Delete the namespace”kubectl delete namespace <namespace> --wait4. Restore
Section titled “4. Restore”--include-namespaces keeps the restore to your namespace, since a policy’s
backup holds every labelled object of the cluster:
velero restore create <restore> --from-backup <backup> --include-namespaces <namespace> --wait5. Check the result
Section titled “5. Check the result”The restore is Completed, every claim Bound, the pods running; then check
the data from inside your application. On PartiallyFailed, read
velero restore logs <restore>.
velero restore describe <restore> --detailskubectl -n <namespace> get pvc,pods6. Resume your GitOps sync
Section titled “6. Resume your GitOps sync”Argo CD adopts the restored objects:
argocd app set <app> --sync-policy automated7. Delete the Restore
Section titled “7. Delete the Restore”Delete it while the module is still on: its finalizer is released only by
the Velero server, and one left behind holds the velero namespace in
Terminating once the module is off.
velero restore delete <restore> --confirmIf the module is already off, remove the finalizer by hand:
kubectl -n velero patch restore <restore> --type merge -p '{"metadata":{"finalizers":null}}'After a lost cluster
Section titled “After a lost cluster”Rebuild the cluster with the same name, in the same account and region,
and turn crossplane and velero on again: Crossplane adopts the bucket
left behind, and Velero reads every backup back from it. Then restore from
step 1. A cluster rebuilt under another name cannot reach the old bucket.
Measured on floci k3s, 2026-10-02: a namespace restored from a node-agent
backup, Completed in 10 s, the file read back unchanged. The full rebuild
on AWS and an EBS snapshot restore are not measured yet.