Page
Run the restore operation on Hub 2
Follow the next steps to move managed clusters from Hub 1 to Hub 2.
Prerequisites:
- Understand how the backup and restore operation works.
- Knowledge of how to install a hub cluster.
- The ability to enable the backup and restore component.
In this lesson, you will:
- Move all managed clusters from Hub 1 to Hub 2.
- Move either the
vb-managed-cls-1or a subset of Hub 1-managed clusters to Hub 2.
Move managed clusters from Hub 1 to Hub 2
To move all managed clusters from Hub 1 to Hub 2, apply the restore resource on Hub 2 by running the following YAML:
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-acm
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: None
veleroManagedClustersBackupName: latest
veleroCredentialsBackupName: latest
veleroResourcesBackupName: latest
```Make sure the cleanupBeforeRestore is set to None to apply the backup data from Hub 1. You do not want to clean up anything from Hub 2 here.
After running this restore resource, all of the backed-up resources from Hub 1 will move to Hub 2, including managed clusters. At the end of this operation, Hub 2 will import and manage all managed clusters.
Move a subset of managed clusters from Hub 1 to Hub 2
In this scenario, you only move vb-managed-cls-1 to Hub 2. Hub 1 continues to manage vb-managed-cls-2.
Move user resources from Hub 1 to Hub 2
Note: This section is optional. Only move user resources if you want to move all user-defined resources (such as applications, policies, and credentials) from Hub 1 to Hub 2.
Apply this restore resource on Hub 2 to move only user-defined resources and exclude any resources created in the managed clusters namespaces. Apply the restore resource by running the following YAML:
```yaml
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: move-managed-clusters-step0
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: None # don't clean up anything, just apply the restore
veleroCredentialsBackupName: latest # move hub credential resources
veleroResourcesBackupName: latest # move hub resources, such as apps, policies
veleroManagedClustersBackupName: latest # move activation resources
excludedResources:
- ManagedCluster # skip any ManagedCluster global resource
excludedNamespaces: # skip ALL managed cluster namespaces
- vb-managed-cls-1
- vb-managed-cls-2
```Move managed cluster resources
Move all vb-managed-cls-1 resources from Hub 1 to Hub 2, except the vb-managed-cls-1 ManagedCluster global resource. To move these resources, apply this restore resource on Hub 2 after the move-managed-clusters-step0 restore status is Finished. This restores all resources from the vb-managed-cls-1-managed cluster namespace.
Apply the restore resource by running the following YAML:
```yaml
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: restore-gh-move-clusters-step1
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: None # don't clean up anything, just apply the restore
veleroCredentialsBackupName: latest
veleroResourcesBackupName: latest
veleroManagedClustersBackupName: latest
excludedResources:
- ManagedCluster # restore everything except the ManagedCluster global resource
includedNamespaces:
- vb-managed-cls-1 # moves all resources, only from the vb-managed-cls-1 namespace
```Move the ManagedCluster global resource
Apply this restore resource on Hub 2 after the move-managed-clusters-step1 restore status changes to Finished. This restores only the vb-managed-cls-1 ManagedCluster global resource, resulting in the activation of vb-managed-cls-1 managed cluster on Hub 2.
Apply the restore resource by running the following YAML:
```yaml
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Restore
metadata:
name: move-managed-clusters-step2
namespace: open-cluster-management-backup
spec:
cleanupBeforeRestore: None # don't clean up anything, just apply the restore
veleroCredentialsBackupName: skip # already moved with restore-gh-move-clusters-step1
veleroResourcesBackupName: skip # already moved with restore-gh-move-clusters-step1
veleroManagedClustersBackupName: latest # restore just managed cluster resources, to initiate the automatic import
includedResources:
- ManagedCluster # restore just ManagedCluster global resources
orLabelSelectors: # get only vb-managed-cls-1 ManagedCluster
- matchExpressions:
- values:
- vb-managed-cls-1
key: name
operator: In
```Verify that you see the vb-managed-cls-1 cluster in the cluster UI on Hub 2, with a status of Ready, as shown in Figure 1.
Clean up moved managed clusters on Hub 1
After you have finished running the restore operation, you can choose to clean up Hub 1 and remove the ManagedClusters resources that were moved to Hub 2. Before you do that, verify that the ManagedClusters resources have successfully moved and connected to Hub 2 by confirming the state is Active on Hub 2. Then, you can remove the ManagedClusters resources from Hub 1.
Note: Make sure the managed clusters status is Unknown on Hub 1 before deleting the ManagedClusters global resource for this managed cluster. Otherwise, the managed cluster detach finalizers run on Hub 1 and workloads will be uninstalled from the managed cluster.
For example, if vb-managed-cls-1 is moved to Hub 2, check that the vb-managed-cls-1 status is Unknown on Hub 1 before trying to remove the ManagedClusters resource for vb-managed-cls-1 from Hub 1.
If not, run the detach finalizers on Hub 1 for the vb-managed-cls-1 cluster and clean up user data from the managed cluster, as shown in Figure 2.
You should see the following statuses on Hub 1 after you removed the vb-managed-cls-1 ManagedClusters global resource (Figure 3).
Resume backup schedule on the hubs
On Hub 2, update the DataProtectionApplication resource to point to the Hub 2 storage location. The following is a YAML sample:
```yaml
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
name: dpa-hub-2
namespace: open-cluster-management-backup
spec:
backupLocations:
- velero:
default: true
objectStorage:
bucket: vb-velero-backup
prefix: hub-2
```Enable the BackupSchedule on Hub 2 by setting the status to paused: false on the BackupSchedule for Hub 2. This creates the Velero schedules and starts a backup schedule.
To enable the BackupSchedule on Hub 1, update the status to paused: false on the BackupSchedule on Hub 1. This creates the Velero schedules and starts a backup schedule on Hub 1.
Summary
In this learning path, you have learned how to use the hub cluster backup and restore the operator available with Red Hat Advanced Cluster Management 2.12 to move managed clusters from one hub to another.
To continue learning, explore the following resources:
