Fusion Backup Manager provides a central view of application backup of all the applications in all the clusters in the Backup Managers domain. From a single view, the OpenShift administrator can determine the state of the backup processes of all of the applications: 

•  which ones succeeded,
• which didn’t complete successfully,
• which were recently restored,
• which namespaces do not have a backup policy assigned.

When it comes to data protection, “Trust, but Verify” is a great practice.

In the Blog, IBM Storage Fusion Backup as Code, JC explains how easy it is to setup backup policies in the form of Custom Resource Definitions (CRDs) and easy for application developers to apply the policy to their namespace via a Custom Resources (CR). Just because it is easy, doesn’t mean that a developer won’t forget to create the Backup CR in their excitement to get the next great application into production. The Fusion Backup Manager dashboard gives the OpenShift administrator the ability to identify which app/dev teams may need help getting their backups setup properly.

Note: The image shows deploying the Backup Manager on the same OpenShift cluster as Red Hat Advance Cluster Manager (ACM). There is no dependency between Fusion Backup and ACM, however collocating makes sense for a couple of reasons. First, using the same management domain scope as ACM for Backup seems logical. Second, if you are going to deploy Fusion Data Foundation Disaster Recovery capabilities, the RamenDR control plane is implemented in ACM. Having DR and Backup management in the same infrastructure also makes sense.

Quick Fusion Backup Overview

• Deployed in a hub and spoke model, with a small Backup-as-a-Service (BaaS) operator installed in each OpenShift Cluster that provides communication to the Backup Manager and executes the backup/restore processes in the cluster.
• Backups are more than just about the PV data; they include images, Custom Resources (Secrets, ConfigMaps, Deploym,ents, …) and state. i.e. everything you need to restore the namespace to a previous point-in-time.
• Backups can be stored locally which provides quick recovery capabilities or exported as an S3 object to provide off-system data protection and enable recovery on another OpenShift cluster.
• Backup policies can be created from the GUI or via Custom Resources definitions. Policies include frequency/time, retention, and backup storage location.
• Backups are executed via BaaS for the application. The backup process can include pre- and post-snap operations such as database quiesce and release. Such operations are defined through a IBM Storage Fusion Backup Recipe Custom Resource.
• A namespace can have more than one policy assignment, i.e backup daily and store locally for 7 days, and backup weekly and store externally for 6 months.

Value of Refactoring an Application for Kubernetes

Every organization is facing the challenge of deciding if they should redesign their applications to run in containers, simply replatform to run in Kubernetes, or run in OpenShift Virtualization (Kubevirt). Fusion Backup 2.4 (known as Backup and Restore Legacy starting with 2.5) was derived from Spectrum Protect Plus designed to operate in VMware environments. Deploying Fusion Backup 2.5 required a minimum of:

• 11 virtual CPUs,
• 16 GiB of memory
• 420 GB of usable disk space

per OpenShift cluster to be backed up.

Fusion Backup 2.6 requires:

• Backup Manager
  • 4 virtual CPUs
  • 16 GiB of memory
  • 200 GB of usable disk space
• BaaS client
  • 2 virtual CPUs
  • 2 GiB of memory
  • 10 GB of usable disk space

For the picture above:

• Virtual CPUs reduced from 33 to 10
• Memory reduced from 48 GiB to 22 GiB
• Usable disk space reduced from 1.2TB to 230 GB

So, as you can see, Fusion customers are going to benefit greatly from our efforts to redesign Fusion Backup to be cloud-native.

One additional thought:

If global warming causing more disasters wasn’t enough for us to worry about when planning for data protection and disaster recovery, Cyber security has (unfortunately) become a very common concern also. If you haven’t looked at IBM Storage Defender, you should. It not only provides ransomware protection, it helps identify ransomware attacks by looking at the behavior of your storage workloads. Defender is coming to OpenShift in the next few months, but in the meantime, you can use Write-Once-Read-Many (WORM) capabilities of many S3 data stores (Ceph, COS to name a couple) to protect your backups from corruption or deletion.

Example: Suppose you have a policy to retain backups for 180 days. You can set up a bucket with a WORM policy for 179 days. Therefore, an antagonist can’t delete or overwrite the backup object.

This isn’t as good as Defender, but a “better than nothing” type solution that is easy to implement until we have Defender for Fusion.

Additional Resources:

Fusion 2.6 Backup Documentation

Fusion Backup Discussion Video

Information on Fusion Recipes: How IBM Storage Fusion Simplifies Backup and Recovery of Complex OpenShift Applications