Consistent backup of containers was always challenging in Kubernetes deployments. Kubernetes historically was designed for stateless workload and only later on became adapted for stateful workloads.

Gitops and Infrastructure as the code approaches simplified backup for Kubernetes stateless workloads by limiting scope only to the backup to the Git repository which stores all source data for Kubernetes workloads.

Kubernetes operators are used to manage Kubernetes production grade stateful workloads and some of them also include backups as part of its own offering. All complexity needed to have consistent backup for stateful workload became fully automated by Kubernetes operators logic and became easy to use by users.

There are cases where there is still a need to have custom backup to cover specific requirements or other solutions mentioned earlier are not usable. In the past Kubernetes cluster operators were forced to create their own in-house custom solutions to be able to have proper backup in place. This approach wasn’t perfect because it lacks portability or covers only specific types of application and usually requires time consuming testing to have production grade solutions when cluster operators are busy with other tasks. Open source community came up with proper backup solution for Kubernetes and over time Velero (Velero) became top software in Kubernetes deployments for custom backups.

Velero offers enough flexibility to cover most of the custom backup needs. Velero matured and became production grade over years of development. It became pretty well tested in different environments because it targets not only a variety of cloud providers that officially support on-premise environments and AWS and Google and Azure cloud providers. Velero community support also other cloud providers with development and testing done outside Velero core team.

Velero was designed to reuse as many existing components as possible and mostly focus on orchestration work. This approach allows us to use high quality existing code and options to make backup reliable and flexible.

Velero reuse following main components:

• Kubernetes platform to run Velero software

• cloud providers object storage to store backup and restore data

• cloud providers libraries and API for block device snapshots

• cloud providers libraries and API for object storage

• Kubernetes CSI drivers for volume snapshots

• Kubernetes CSI libraries and API for volume snapshots

• Restic and Kopia software for file system backup

Velero go way beyond common way of backup usages and could be used for following scenarios:

• data protection

• disaster recovery

• data migration - migration could be done between Kubernetes clusters in single cloud vendor or even between different cloud vendors

Velero supports different way of doing backup based of Kubernetes runtime environment:

• block devices snapshots with specific driver - require specific cloud provider support

• file system backup with Restic or Kopia - they don’t require any cloud provider support

• volume snapshots with Kubernetes CSI driver

Most applications that require custom backup also require extra steps or commands to provide consistent data for backup. Velero supports this need via hooks that could be executed before and backup. Velero also allows for a customizable restore process with support of hooks that could execute before and after the restore process done by Velero.

Software deployments lifecycle on Kubernetes clusters could be quite complex and could require moving workloads between Kubernetes clusters in the same cloud vendor or even move to the different one. Velero supports this option and extends the usage of backup to cover migration of workloads with data between different Kubernetes clusters. The way this is achieved is to use basic Velero operation to backup workload with data on one cluster and restore to another.

Velero support not only migration between the same version of Kubernetes clusters but also between different versions of Kubernetes clusters. The main problem for migration between different versions of Kubernetes clusters is that Kubernetes API has a lifecycle that introduces newer versions of API and deprecates and removes older versions over time. Kubernetes objects API could be deprecated and removed in newer version of Kubernetes cluster and because of that deployed objects that are migrate to much newer Kubernetes cluster could require conversion. In most cases Velero support seamless migration to newer version of API when Kubernetes API allow for this kind of transition. Seamless transition to newer version of Kubernetes API is supported and documented by Kubernetes. There are also cases when difference between Kubernetes clusters API is too large to be supported with seamless migration and require cluster operator for extra manual migration steps.