Blog

AWS and Azure Backup and Restore of Red Hat OpenShift Services

Here in this blog, we will learn about AWS and Azure Backup and Restore of Red Hat OpenShift Services.

Background

Backup is the process of making copies of data and storing them in different places or media, whereas restoration is the process of obtaining the backed-up data and transferring it to a new system or location if necessary. In other words, a restoration is essentially data retrieval, but a backup is similar to data preservation.
I’ll go over a number of things to keep in mind when backing up and restoring both Red Hat OpenShift Service on AWS (ROSA) and Azure Red Hat OpenShift (ARO) clusters in this article. Finally, I’ll talk about the tools that can be used to support backup and restore procedures. I’ll also cover what should be backed up. This article’s main goal is to discuss top-level recommended practices for backup and restore for your ROSA and ARO clusters.

Considerations

I strongly advise performing backup and restore operations at the application level as opposed to the cluster level. Note that all of the ensuing considerations fall under this.

• • Plan for disaster recovery (DR)

• • • Fault Tolerant (FT) vs. High Availability (HA)
    • Recovery Time Objective (RTO) in comparison to Recovery Point Objective (RPO)

  • Frequency

  • • Your RPO and RTO, as previously mentioned, define how frequently you must perform backups. To meet the RPO in the previous example, you would need to do backups at least once every hour.

  • Location

  • • You might think about dividing your clusters across several availability zones (AZs) and/or regions to guarantee that your systems are still accessible in the event of a failure. In other words, if you presently only have one cluster in one AZ, you might want to think about replicating your cluster over several AZs. In the same way, you might want to make sure that your cluster can fail over to a different area in the case that the region experiences a disaster.

  • Security

  • • Another crucial factor to take into account is security, as you don’t want anyone with the wrong authorization or authentication to access your backup data. Nevertheless, you ought to limit who has access to this information. The backup should be encrypted both in transit and at rest and kept in a safe location.

  • Automation

  • • Automating the backup and restore procedures might be a good idea. Below, I’ll go over the tools that can aid you in the process.

  • Check and recheck

  • • Finally, you need to make sure that all plans that take into account the aforementioned factors have been tested, validated, documented, and maintained. In disaster recovery circumstances, this will guarantee that the backup and restoration procedures are operating as intended.

Any DR plan must take both HA and FT into account. The goal is to keep downtime to a tolerable level because designing applications with HA in mind will result in minimal downtime, such as during failover or maintenance.

On the other hand, by creating FT systems, no downtime will be experienced and the systems as a whole will continue to function properly even if any of its components fail. As a result, these systems may frequently recover in real-time without user input.
Briefly stated, the former design is typically used for applications that can tolerate some downtime while the latter is utilized for essential applications where delay is intolerable.

The organization’s RPO and RTO are important factors to take into account in the DR plan. While RTO is referred to as the allowed downtime before the systems recover, RPO refers to the acceptable amount of data loss in the event of a disaster.

Let’s assume that your RPO and RTO are both one hour. This means that if a disaster strikes at 12 o’clock, you could only tolerate data loss up to 11 o’clock, and your systems had to go back to work by 1 o’clock.

What to Support

Think about this at the application level when deciding what has to be backed up. The first guideline is that backing up etcd is not recommended because it is highly improbable that your new cluster will be an exact replica of the one you are about to backup. so avoid backing up etcd!

• • Namespaces

  • • Choose the namespaces that are essential to your applications.

  • Custom Resource Definitions (CRDs) and Custom Resources (CRs)

  • • Decide which CRs and CRDs are pertinent to your cluster together with your namespaces.

  • Manifests in YAML

  • • Choose which YAML manifests you want to back up and give priority to.

  • PVs (Persistent Volumes)

  • • If your cluster uses PVs, find out whether the volumes are inside the cluster or outside it, and think about how to backup
      those volumes.

Tools

Let’s talk about a few tools that can assist you with backup and restore procedures before we wrap up.

• • CI/CD and GitOps

  • • In the backup and restore operations, automation is a crucial factor to take into account. GitOps facilitates change
      tracking and may be useful in determining the reason for data loss during backup and restore. The deployment of
      backups and the processes themselves can also be added to CI/CD pipelines, enabling you to run and test the processes
      frequently.

  • Data protection API for Red Hat OpenShift

  • • With the help of the OADP API, you may use the external backup and recovery tools of your choice to communicate
      with OpenShift clusters, assuring the availability and recoverability of the application data in the event of a disaster. For
      more information, please see this link.

  • Container Migration Toolkit (MTC)

    • MTC, on the other hand, is a toolkit that offers resources and tools for moving applications between Red Hat OpenShift clusters or within the same cluster. Observe this link for further details.

  • external resources

    • We also recommend Konveyor, Velero, Kasten K10, and Portworx as additional third-party tools.