Overview of Container Backup Support

IBM Spectrum® Protect Plus Container Backup Support protects data of persistent volumes, namespace-scoped resources, and cluster-scoped resources that are associated with containers in a Kubernetes or Red Hat® OpenShift® environment. You can run snapshot backup operations to create locally stored backup copies in the cluster, or you can run backup copies to the vSnap server for longer-term retention.

Data of persistent volumes, namespace-scoped, and cluster-scoped resources can be protected by using a container service level agreement (SLA) policy that specifies how often snapshot and copy backups are created and how long they are retained. If data on the original volume is damaged or lost, the volume can be restored from either the snapshot or copy backups on the vSnap server. If data in any resource is damaged or lost, that data can also be restored.

Supported storage types

Container Backup Support protects volume data that was allocated by a storage plug-in that supports the Container Storage Interface (CSI) provided for Kubernetes. Container Backup Support is fully tested with Ceph® RADOS Block Device (RBD), Ceph File System (CephFS), IBM Spectrum Scale, and IBM Spectrum Virtualized storage environments. The CSI plug-in provides snapshot capabilities that are used for backup operations.

For persistent volumes with a block-based storage type, such as Ceph RBD and IBM Spectrum Virtualized, block-based copy backup and restore operations are performed. For persistent volumes with a file system-based storage type, such as CephFS and IBM Spectrum Scale, file-based, incremental copy backup and restore operations are performed. During incremental backups, only new and changed data is copied to the IBM Spectrum Protect Plus vSnap server.

For IBM Spectrum Scale backup operations, snapshots can be created only from independent fileset-based persistent volume claims (PVCs). PVCs that are based on lightweight directories and dependent file sets are not supported. These types of PVCs are automatically filtered and are not displayed in the container inventory in the IBM Spectrum Protect Plus user interface.

Deployment overview

The following figure shows how Container Backup Support is deployed in the Kubernetes or OpenShift environment and how it interacts with IBM Spectrum Protect Plus:

Figure 1. Container Backup Support deployment diagram

If you want to deploy Container Backup Support as a snapshot-only solution, the installation of the IBM Spectrum Protect Plus vSnap server is not required. When a schedule is run, snapshots are saved only on the storage system in your cluster; data is not copied to the vSnap server. With a snapshot-only deployment, data cannot be restored to another cluster.

Data mover container

Two types of data movers are deployed with IBM Spectrum Protect Plus. One is deployed as a container in a namespace where persistent volume claims (PVCs) exist. The other type, MinIO for resources, is deployed to the BaaS namespace. Data mover containers communicate with the IBM Spectrum Protect Plus instance outside of the Kubernetes or OpenShift environment for copy backup support as follows:

The first type of data mover is deployed in the application namespaces.
The second type of data mover is deployed in the BaaS namespace and copies resource data from MinIO to the vSnap server.

Container Backup Support uses PVCs to identify the persistent volumes to back up. For copy backup operations, when a schedule is run, snapshots and copy backups of a PVC are created at the time intervals that are specified by the SLA. The data mover copies the data and records the snapshot backups in the IBM Spectrum Protect Plus Jobs and Operations window. Snapshots that are created by on-demand backups are also recorded in IBM Spectrum Protect Plus.

Kafka cluster

The Kafka cluster handles messaging operations between the application agent and data movers. The Kafka cluster is managed by Red Hat AMQ Streams, which is an implementation of Strimzi, an operator that implements clusters of Apache Kafka. An operator is a container that configures, installs, maintains, and uninstalls, in this case, the Apache Kafka containers.

For example, in the OpenShift environment, the Kafka cluster is described by the following pods:

amq-streams-cluster-operator-v1.5.3-5b795f4c69-gdsrx   1/1     Running            0          24m
baas-entity-operator-c99f4c49b-p9v9c                   3/3     Running            1          24m
baas-kafka-0                                           2/2     Running            0          23m
baas-zookeeper-0                                       1/1     Running            0          23m
baas-zookeeper-1                                       1/1     Running            0          35m
baas-zookeeper-2                                       1/1     Running            0          30m

The Kafka cluster consists of three zookeeper pods that form the storage system for Kafka, and a single Kafka application pod that sends and retrieves messages. The entity-operator pod is installed by the cluster-operator pod to manage local changes to the cluster. The cluster-operator pod is the only deployment that is described in the installation. On Kubernetes, the cluster-operator pod is called baas-strimzi-cluster-operator. On OpenShift, the cluster-operator pod is called amq-streams-cluster-operator.

On Kubernetes, Strimzi is installed along with the Container Backup Support product. When you update Container Backup Support, Strimzi is updated automatically.

On OpenShift, the installation files for Red Hat AMQ Streams are not provided by the Container Backup Support software. Instead, the Container Backup Support deployment requests an installation of Red Hat AMQ Streams from the OpenShift Operator Hub. Over time, the Operator Hub provides maintenance and updates of the Red Hat AMQ Streams operator and associated containers. A new version of the Container Backup Support software is not necessary to install patches and security updates to Red Hat AMQ Streams.

Multitenancy support

Container Backup Support manages backup and restore operations by using custom resources. All backup and restore objects belong to a Kubernetes or OpenShift namespace. The cluster administrator can restrict access to these objects. With controlled access, multiple users can run backup and restore requests in the same Kubernetes or OpenShift cluster. The backup and restore objects inherit a namespace from the PVC that identifies the persistent volume for backup and restore operations. For more information about multitenancy, see Security features in Container Backup Support.

Red Hat OpenShift Virtualization support

In Red Hat OpenShift clusters with the OpenShift Virtualization feature, virtual machines (VMs) that are running within an OpenShift container are protected during Container Backup Support backup jobs. The VMs must be allocated on storage that supports CSI.

All backup operations are PVC based. VMs are protected as part of PVC backup jobs. The backup operation has no explicit knowledge of workloads that are running within the PVC. To back up or restore a VM, use Container Backup Support to back up or restore the relevant PVC. You can also back up and restore cluster-scoped or namespace-scoped resources. Custom resource data for VMs is saved during resource backup jobs.

Important: For data to be consistent, the VMs must be powered off before a backup or restore job begins. After restoring a PVC, use the restored PVC as the source to re-create the VM. For more information, see Preparing to restore persistent volumes that have VMs on OpenShift clusters.