|
| 1 | +// Module included in the following assemblies: |
| 2 | +// |
| 3 | +// * backup_and_restore/application_backup_and_restore/advanced-topics.adoc |
| 4 | + |
| 5 | + |
| 6 | +:_content-type: CONCEPT |
| 7 | +[id="oadp-about-backing-and-restoring-from-cluster-to-cluster_{context}"] |
| 8 | += About backing up data from one cluster and restoring it on another cluster |
| 9 | + |
| 10 | +{oadp-first} is designed to back up and restore application data in the same {product-title} cluster. {mtc-full} ({mtc-short}) is designed to migrate containers, including application data, from one {product-title} cluster to another cluster. |
| 11 | + |
| 12 | +You can use OADP to back up application data from one {product-title} cluster and restore it on another cluster. However, doing so is more complicated than using {mtc-short} or using OADP to back up and restore on the same cluster. |
| 13 | + |
| 14 | +To successfully use OADP to back up data from one cluster and restore it to another cluster, you must take into account the following factors, in addition to the prerequisites and procedures that apply to using OADP to back up and restore data on the same cluster: |
| 15 | + |
| 16 | +* Operators |
| 17 | +* Use of Velero |
| 18 | +* UID and GID ranges |
| 19 | +
|
| 20 | +[id="oadp-cluster-to-cluster-operators_{context}"] |
| 21 | +== Operators |
| 22 | +You must exclude Operators from the backup of an application for backup and restore to succeed. |
| 23 | + |
| 24 | +[id="oadp-cluster-to-cluster-velero_{context}"] |
| 25 | +== Use of Velero |
| 26 | + |
| 27 | +Velero, which OADP is built upon, does not natively support migrating persistent volume snapshots across cloud providers. To migrate volume snapshot data between cloud platforms, you must _either_ enable the Velero Restic file system backup option, which backs up volume contents at the filesystem level, _or_ use the OADP Data Mover for CSI snapshots. |
| 28 | + |
| 29 | +[NOTE] |
| 30 | +==== |
| 31 | +In OADP 1.1 and earlier, the Velero Restic file system backup option is called `restic`. |
| 32 | +In OADP 1.2 and later, the Velero Restic file system backup option is called `file-system-backup`. |
| 33 | +==== |
| 34 | + |
| 35 | +[NOTE] |
| 36 | +==== |
| 37 | +Velero's file system backup feature supports both Kopia and Restic, but currently OADP supports only Restic. |
| 38 | +==== |
| 39 | + |
| 40 | +* You must also use Velero's link:https://velero.io/docs/main/file-system-backup/[File System Backup] to migrate data between AWS regions or between Microsoft Azure regions. |
| 41 | +* Velero does not support restoring data to a cluster with an _earlier_ Kubernetes version than the source cluster. |
| 42 | +* It is theoretically possible to migrate workloads to a destination with a _later_ Kubernetes version than the source, but you must consider the compatibility of API groups between clusters for each custom resource. If a Kubernetes version upgrade breaks the compatibility of core or native API groups, you must first update the impacted custom resources. |
| 43 | + |
| 44 | +[id="oadp-cluster-to-cluster-uid-and-gid-ranges_{context}"] |
| 45 | +== UID and GID ranges |
| 46 | + |
| 47 | +When you back up data from one cluster and restore it to another cluster, there are potential issues that might arise with UID (User ID) and GID (Group ID) ranges. The following section explains these potential issues and mitigations: |
| 48 | + |
| 49 | +Summary of issues:: |
| 50 | +The UID and GID ranges of the namespace might change on the destination cluster. OADP does not back up and restore OpenShift UID range metadata. If the backed application requires a specific UID, ensure the range is available when restored. For more information about OpenShift's UID and GID ranges, see link:https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids[A Guide to OpenShift and UIDs]. |
| 51 | + |
| 52 | +Detailed description of issues:: |
| 53 | +When you create a namespace in {product-title} by using the shell command `oc create namespace`, {product-title} assigns the namespace a unique User ID (UID) range from its available pool of UIDs, a Supplemental Group (GID) range, and unique SELinux MCS labels. This information is stored in the `metadata.annotations` field of the cluster. This information is part of the Security Context Constraints (SCC) annotations, which comprise the following components: |
| 54 | + |
| 55 | +* `openshift.io/sa.scc.mcs` |
| 56 | +* `openshift.io/sa.scc.supplemental-groups` |
| 57 | +* `openshift.io/sa.scc.uid-range` |
| 58 | + |
| 59 | ++ |
| 60 | +When you use OADP to restore the namespace, it automatically uses the information in `metadata.annotations` without resetting it for the destination cluster. As a result, the workload might not have access to the backed up data if one of the following is true: |
| 61 | + |
| 62 | +* There is a pre-existing namespace with different SCC annotations, for example, on a different cluster. In this case, at backup time, OADP reuses the pre-existing namespace instead of the namespace you are trying to restore. |
| 63 | +* The backup used a label selector, but the namespace where workloads run on does not have the label on it. In this case, OADP does not back up the namespace, but instead creates a new namespace during restore that does not include the annotations of the namespace you backed up. This causes a new UID range to be assigned to the namespace. |
| 64 | ++ |
| 65 | +This might be an issue for customer workloads if {product-title} assigns a pod a `securityContext` UID based on namespace annotations that have changed from the time the persistent volume data was backed up. |
| 66 | +* The container UID no longer matches the UID of the file owner. |
| 67 | +* An error occurs because {product-title} did not modify the UID range of the destination cluster to match the data of the backup cluster. As a result, the backup cluster has a different UID than the destination cluster, which means the application cannot read or write data to the destination cluster. |
| 68 | + |
| 69 | +Mitigations:: |
| 70 | + |
| 71 | +You can use one or more of the following mitigations to resolve the UID and GID range issues: |
| 72 | + |
| 73 | +* Simple mitigations: |
| 74 | + |
| 75 | +** If you use a label selector in the `Backup` CR to filter the objects to include in the backup, be sure to add this label selector to the namespace that contains the workspace. |
| 76 | +** Remove any pre-existing version of a namespace on the destination cluster before attempting to restore a namespace with the same name. |
| 77 | + |
| 78 | +* Advanced mitigations: |
| 79 | +** Fix UID ranges after migration by performing steps 1-4 of link:https://access.redhat.com/articles/6844071[Fixing UID ranges after migration]. Step 1 is optional. |
| 80 | + |
| 81 | +For an in-depth discussion of UID and GID ranges in {product-title} with an emphasis on overcoming issues in backing up data on one cluster and restoring it on another, see link:https://cloud.redhat.com/blog/a-guide-to-openshift-and-uids[A Guide to OpenShift and UIDs]. |
0 commit comments