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.

Change required here 
related jirra https://issues.redhat.com/browse/ACM-12757
PR https://github.com/stolostron/rhacm-docs/pull/6974 

https://github.com/stolostron/rhacm-docs/blob/2.12_stage/business_continuity/backup_restore/use_existing_hub_cluster.adoc

This is not what was intended to be doc originally (https://docs.google.com/document/d/1hmayCAmkt2Zu1u8OIrjsFwHh3aJTE8vlWf63tWCSxZA/edit#heading=h.4u52sowlllor ) 

A detached managed cluster has content that does not match the content of the backup hub cluster. When you run a restore operation on your hub cluster that already manages some clusters and the cleanupBeforeRestore option set to CleanupRestored, the following outcomes occur:

• Only when an earlier backup creates the ManagedCluster resources, the velero.io/backup-name: backupName label annotation is set, and the backup managed clusters are not part of the restored backup, managed clusters are detached and the data is cleaned on the managed clusters.

• When the ManagedCluster resources are not created by an earlier backup and do not have the velero.io/backup-name: backupName label annotation, ManagedCluster resources are not cleaned up. The managed clusters continue to be managed by your hub cluster.

Issues :
1. A detached managed cluster has content that does not match the content of the backup hub cluster.  - This is incorrect, was never part of the google doc
2. Only when an earlier backup creates the ManagedCluster resources .. - this is confusing and doesn't match the initial point in the google doc (If an earlier backup created the ManagedCluster resources, then ..)

Please change with above paragraph with :

If the hub cluster you plan to use for the restore operation already manages some clusters, expect the following outcome when you run a restore operation with the ` cleanupBeforeRestore` option set to CleanupRestored :

• If the ManagedCluster resources were created by a restored backup, then they have the `velero.io/backup-name: backupName` label annotation set. Therefore, if the user runs a restore operation and uses the ` cleanupBeforeRestore=CleanupRestored` option, the managed clusters are detached if they are no longer part of the current restored backup.
•  If the ManagedCluster resources were created by the user and not by a restored backup, then they don't have the `velero.io/backup-name: backupName` label annotation. Therefore, if the user runs a restore operation and uses the ` cleanupBeforeRestore=CleanupRestored` option, these managed clusters resources will not be cleaned up even if they are not part of the restored backup.