Persistent Volume Claim Backup

All Pods in Kubernetes are ephemeral and may be destroyed manually or by operations from controllers. Pods do not store data locally because stored data would be destroyed with a pod’s life cycle management, so data is saved on Persistent Volumes using Persistent Volume Claim objects to control Volume Space availability.

This brings a new challenge to data backup. Fortunately most of the challenges found here are similar to standard bare metal or virtualized environments. As with bare metal and virtual machine environments, data stored in databases should be protected with dedicated Bacula Enterprise plugins that take advantage of the database backup routines.

See the appropriate Bacula Enterprise plugin documentation for more details on database backups.

On the other hand, most non-database applications store data as simple flat files we can backup as-is without forcing complicated transactions or data consistency procedures. This use case is handled directly with the Kubernetes Plugin using a dedicated Bacula Backup Proxy Pod executed in the cluster.

If the container application is more complex, it is possible to execute commands inside the container to quiesce the application:

before the volume cloning or snapshot
after the volume cloning or snapshot
after the backup of the container.

The execution of a command may cause the backup of the container to be terminated due to an issue with the run.*.failonerror annotation. You can find detailed description of this feature here.

A Bacula Backup Proxy Pod is a service executed automatically by the Kubernetes Plugin which manages secure access to Persistent Volume data for the plugin. It is executed on the Kubernetes cluster infrastructure and requires a network connection to the Kubernetes Plugin for data exchange on backup and restore operations. No external cluster service like NodePort, LoadBalancer, Ingress or Host Based Networking configuration is required to use this feature.

It is also not required to permanently deploy and run this service on the cluster itself as it is executed on demand. The Bacula Backup Proxy Pod does not consume any valuable compute resources outside of the backup window. You can even operate your Kubernetes backup solution (Bacula Enterprise service with Kubernetes Plugin) directly from your on-premise backup infrastructure to backup a public Kubernetes cluster (it requires a simple port forwarding firewall rule) or use public backup infrastructure to back up on-premise Kubernetes cluster(s). Support for these varied architecture modes is built into the Kubernetes Plugin. It is designed to be a One-Click solution for Kubernetes backups.

Starting from Bacula Enterprise version 12.6.0, you can back up and restore any PVC data including PVCs not attached to any running Kubernetes Pod. This removes a previous limitation in this area.