Overview
Velero gives you tools to back up and restore your Kubernetes cluster resources and persistent volumes. You can run Velero with a cloud provider or on-premises.
Velero lets you:
Take backups of your cluster and restore in case of loss.
Migrate cluster resources to other clusters.
Replicate your production cluster to development and testing clusters.
Velero supports backup operation of volumes with file system backup (Velero Docs - File System Backup ) via node agent (Restic or Kopia) or volume snapshot (native driver for cloud providers or K8s csi driver).
File system backup is used in deployments that don’t support volume snapshots operation like on-premise deployments. File system backup requires an extra Velero component node agent which executes Restic or Kopia software to backup files.
Volume snapshots are used in deployments that support durable volume snapshots in cloud providers like Google, AWS or Azure. Other cloud providers should be verified before use if they are supported and safe to use because snapshots should persist in separate storage that volume itself.
Velero backup K8s objects and volumes. K8s objects and volumes in file system backup are stored in object storage. Backup of volumes in snapshot mode use cloud provider interface to execute and store volume snapshots.
Architecture
Velero consists of:
A server (Velero controller) that runs on your cluster
Node agent run on all cluster nodes which is only needed for file system backup mode (not needed for volume snapshot mode)
A command-line client (Velero cli) that runs locally and allow to interact with Velero system
Velero support operations like backup for backup process and restore for restore process that could be run via:
Velero cli command for imperative approach
K8s manifests with Velero K8s custom resources for declarative approach
Velero requires that all Velero objects (K8s manifests) need to be defined in the same namespace where Velero has been installed.
Custom architecture and setup
Velero supports backup and migration and disaster recovery in the same deployment. Because of that custom installation with proper naming of objects is needed to support all of them and avoid issues over time.
Proposed custom installation use concept of local cluster and remote cluster.
Local clusters are always configured as a single instance for one installation and remote clusters could be configured multiple times for one installation.
Difference between local and remote clusters is related to the local ones user read-write approach and remote cluster is only used in read-only mode to avoid any accidental removal of existing backups.
Following documentation for simplicity uses only one local cluster (cluster-1) and one remote cluster (cluster-2).
Local cluster (cluster-1) is used for locally deployed Velero and is used for backup and restore processes.
Remote cluster (cluster-2) is used as extra configuration that is only used for the restore process.
Velero uses object storage to store backup data.
Bucket names used by Velero should consist of Velero name prefix and cluster name (velero-cluster-1 and velero-cluster-2). Velero instances in both clusters use separate buckets for each Velero instance.
Velero to access object storage use Velero custom resource BackupStorageLocation which names are derived from cluster names to provide uniqueness and avoid name collisions when local cluster and multiple remote clusters are used in the single Velero installation.
Local cluster has read-write access to the bucket and remote cluster has read-only access to the bucket.