Note: Doc team updates the current version of the documentation and the
two previous versions (n-2), but we address *only high-priority, or
customer-reported issues* for -2 releases in support.
Describe the changes in the doc and link to your dev story:

1. - [x] Mandatory: Add the required version to the Fix version/s field.

2. - [ ] Mandatory: Choose the type of documentation change or review.

• [x] We need to update to an existing topic

• [ ] We need to add a new document to an existing section

• [ ] We need a whole new section; this is a function not
  documented before and doesn't belong in any current section

• [ ] We need an Operator Advisory review and approval

• [ ] We need a z-Stream (Errata) Advisory and Release note
  for MCE and/or ACM

3. - [ ] *Mandatory: *Use the following link to open the doc and find where the
documentation update should go. Note: As the feature and doc is
understood and developed, this placement decision may change:

• Published doc: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10
• Source: https://github.com/stolostron/rhacm-docs

4. - [ ] Mandatory for GA content:

• [ ] Add steps, the diff, known issue, and/or other important
  conceptual information in the following space:

• [ ] *Add Required access level *(example, *Cluster
  Administrator*) for the user to complete the task:

• [ ] Add verification at the end of the task, how does the user
  verify success (a command to run or a result to see?)

• [ ] Add link to dev story here:

5. - [ ] Mandatory for bugs: What is the diff? Clearly define what the
problem is, what the change is, and link to the current documentation. Only
use this for a documentation bug.

This is related to slack discussion

https://redhat-internal.slack.com/archives/C0282HW2YHZ/p1726775763108449?thread_ts=1726768771.296459&cid=C0282HW2YHZ

It's hard to find the information that you need to use a new hub for a restore operation, is is buried under the https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html/business_continuity/business-cont-overview#restoring-data-primary-hub

Change:

At this link

https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html/business_continuity/business-cont-overview#prepare-new-hub

Add the following content at the beginning :

When you need to restore backup data on a cluster, create a new cluster instead of using the primary hub cluster or a hub cluster where user resources were created before the restore operation. 

The main reason for using a new cluster is that in a DR scenario, when you restore the hub backup to the passive hub, you want to end up with a hub cluster identical with the one that went down.  There should be no extra user resources such as apps, policies and no extra managed clusters.

Another reason for using a new hub cluster is that as you restore the backup on this hub, if you have managed clusters already managed by this hub, the restore operation may detach them and delete their cluster resources in an effort to clean up resources which are not part of the restored backup ( so that the cluster is identical in content with the initial hub ). So in this case you may lose user data as the managed clusters workloads are deleted as part of the detach action.