Background information
Раздел «Cluster administrator»: быстрый переход по подразделам
Backup and snapshot
| Aspect | Backup (Velero) | Snapshot |
|---|---|---|
| What is saved | Resources and volumes by backup selector (namespaces, types, labels). | A copy of the volume at the storage level (CSI, etc.). |
| Recovery result | The status of objects included in the backup. Not “the whole system.” | The state of the volume at the time of the snapshot. |
| Granularity | Kubernetes objects. | Volume blocks/data. |
| Connections | When you select PVC, the associated PV is added to the backup. | Independent of the Kubernetes resource model. |
| Typical Application | Application recovery, transfer between clusters, DR. | Fast volume recovery, cloning. |
The backup copy does not replace a snapshot of the entire cluster: only those resources that were included in the backup are involved in the recovery.
Backup behavior (Velero and platform)
- Selective selection — include and exclude lists of namespaces and resource types (
included/excludedby scope), plus labels. Velero treats empty lists as “everything except what is excluded”.*in a list means every resource or namespace in that scope;excludedNamespaces: ["*"]is invalid. How the form maps to these fields — creating backups. An individual object can be marked withvelero.io/exclude-from-backup=true(Backup Reference (v1.17), Resource filtering (v1.17)). - Automatic CSI snapshot exclusion — from Velero v1.17.0 (platform 2.13.1) the controller forcibly excludes
volumesnapshots.snapshot.storage.k8s.ioandvolumesnapshotcontents.snapshot.storage.k8s.iofrom regular resource collection. Details — shturval-backup. - Namespace
velerois excluded automatically. defaultVolumesToFsBackup- if the value is “yes”, pod volumes are copied via file system backup (the general scheme is described in File System Backup (v1.17)). When disabled, volumes use provider-level mechanisms (CSI snapshots, etc.) if available in the cluster. For a full backup of a cluster with volumes, it is recommended to disable file copying for all volumes to reduce the risk of errors during recovery.- BackupRepository and kopia — when backing up from PV, a structure with backup data and a kopia directory are created in object storage. Repositories in kopia are tied to namespaces with backed up PVs, and not to individual
Backupobjects. In the namespaceveleroresourcesBackupRepositoryare created (including those with the namespace name prefix). - Deleting a backup — deleting only the
BackupCR in Kubernetes does not remove data from storage; usevelero backup deletefor complete removal (Backup Reference (v1.17)). Deleting the CR does not immediately remove kopia repositories; cleanup runs via maintenance (quick maintenance frequency is set onBackupRepository, for examplemaintenanceFrequency, default 1 hour; full maintenance runs automatically). Complete removal of traces can take weeks after deleting the backup. Check maintenance logs in Job resources in namespacevelero(only the last few jobs are retained). - Object storage with immutability - object immutability modes for different providers prevent updating backup metadata in the storage; behavior depends on the policy type and provider (Backup Reference (v1.17)).
Restore behavior
- Asynchrony - status in
Restore. - Restore source — check
status.phase: restore from a named backup after it finishes (CompletedorPartiallyFailed); from a scheduler Velero uses the latest backup created by that scheduler with statusCompleted, see When restore is possible. - Policy for existing resources —
none(do not overwrite) orupdate(update on conflict); restore filters areincludedResources/excludedResourcesandincludedNamespaces/excludedNamespaces, see the restore page. - PV in use - volumes mounted in running pods are not restored (Deployment, StatefulSet, Pod).
- Order - resources are restored in the order calculated by Velero taking into account dependencies (Restore Reference (v1.17)).
- Resources outside the backup are not affected.
Recommendations
- Connect S3-compatible storage before the first backups.
- For regular copies, use
Schedule(cron orCRON_TZ=). - Separate backups according to purpose (critical namespaces, “full” cluster, DR).
- For a full backup of a cluster with PV, disable
defaultVolumesToFsBackupfor the corresponding backups. - Set TTL based on storage capacity and storage policy.
- Periodically check restore on the test cluster or test namespace.
- Do not delete backup data directories (restic/kopia) in object storage manually without the agreed deletion of
BackupRepository- otherwise errors likeError checking repository for stale locksare possible. - For pods with hostPath, if necessary, set the annotation
backup.velero.io/backup-volumes-excludeswith a list of volume names. - management cluster recovery scenarios - see Cluster recovery.
Documentation Velero v1.17
Reference for CLI, CRD fields and restrictions: Velero v1.17 Docs.