IBM Fusion backup services

Creating and managing backups is a key aspect of data resiliency. For this purpose, IBM Fusion Data Foundation can take advantage of the additional backup and restore service, which IBM Fusion provides on top of the storage infrastructure.

This service covers backup and restore of the Kubernetes resources, application metadata, and a snapshot of the persistent volumes (PVs) for a particular application namespace. Namespaces and labels are being used to define, which content belongs to which application and what needs to be included in a backup. The scoping by namespaces makes the backup specific to an application, rather than mirroring the entire Red Hat OpenShift cluster in one piece as a bulk.

The IBM Fusion backup service is comprising two parts:

• One hub server coordinates the backups and needs to be deployed outside of the IBM Fusion (Data Foundation) cluster.
• Multiple spoke clients, which run a lightweight agent inside the cluster and perform the backup themselves. The underlying implementation is based on open source components Velero, restic, and CSI snapshots.

The separation of Hub and Spoke supports multi-cluster concepts and separates the workload between the individual clusters. Interoperability is a tremendous achievement of this concept. Backups can be exchanged across different cluster deployments, cluster versions, and across different cloud storage providers. This is a true hybrid cloud solution.

Created backup archives are stored into an object storage, which is located in a safe place either on-premises or remotely. The target destination of the backup archive needs to expose the commonly used S3 API for object storage, which gives several options including:

• Local deployments of object storage on a hardware architecture of choice
  • IBM Storage Scale cluster extension services offering S3
  • Another cluster of IBM Fusion
  • IBM Storage Ceph
  • Standalone deployment of a Noobaa MCG gateway
  • Other 3rd party offerings
• Public cloud storage by a cloud provider like IBM Cloud Object Storage or AWS

As S3-compatible object storage is gaining relevance (also in the context of AI workload), an enterprise-wide object storage is often a core part of a customer IT strategy.

As described in the previous section, you must consider one important aspect when planning for resiliency. In the context of Kubernetes and containerized workload, the scope of backup is not the full disk mirroring of a system. In particular, a backup does not include the cluster-wide artifacts, nor does it backup installation or topology configuration. For example, hypervisor settings or the specific compute/control node layout of the cluster (like the etcd database) need to be part of the automation or scripting, which is used to install the cluster in the first place. This implies that a resilient environment requires automation to quickly deploy a fresh environment and cluster, whenever needed. For example, after a disaster strikes. The restore procedure can then re-create the application state and application data on top based on the backup archive.