Velero

Recreating application pods is not enough after losing the configuration and data they depend on. Velero coordinates backup and restore of Kubernetes resources and, through selected mechanisms, persistent volume data. Teams use it for recovery and some cluster-to-cluster moves. Resource backups, storage snapshots and file-system backups protect different things, so decide how each workload’s actual data is covered. A completed backup needs a restore rehearsal that checks application consistency and works without relying on the original storage.

Current guidance

This entry’s original link was the stable/velero chart. Current chart maintenance lives with the Velero project, and deployments need compatible provider plugins plus correctly scoped BackupStorageLocation and snapshot configuration. Decide separately how Kubernetes objects and persistent data will be protected; enabling one mechanism does not prove that every volume is included.

Velero documents native or CSI snapshots and file-system backup through its node agent. File-system backup reads mounted live files, which can be inconsistent for a busy database unless the workload is coordinated appropriately. The documented mechanism has volume-type and privilege limitations; hostPath is not equivalent to a supported local persistent volume. Snapshot availability also does not necessarily mean the data has been copied away from the original storage failure domain.

Define a restore drill that loses access to the original workload and checks the replacement’s files, database consistency, secrets, permissions and service endpoints. Record the backup duration, recoverable point and practical restore time. Preserve repository credentials and plugin compatibility through upgrades, and check existing backups before changing retention. A related database logical-restore example demonstrates a narrower technique; it does not certify Velero or application-consistent cluster recovery.