Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template. 

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

Always look at the current documentation to describe the change that is needed. Use the source or portal link for Step 4:

 - Use the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes

 - Use the GitHub link to find the staged docs in the repository: https://github.com/stolostron/rhacm-docs 

Describe the changes in the doc and link to your dev story

Provide info for the following steps:

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

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

      - [ ] New topic in an existing section or new section
      - [ x] Update to an existing topic

3. - [ ] Mandatory for GA content:
            
       - [ ] Add steps and/or other important conceptual information here: 
       
            
       - [ ] Add Required access level for the user to complete the task here:
       

       - [ ] 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:

4. - [ ] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation:

2 issues with this section :

https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.8/html/business_continuity/business-cont-overview#restore-imported-managed-clusters

1. A bit inaccurate ( you want to do this ONLY when the passivation data is restored )
   The text: When you restore a backup on a new hub cluster, make sure that the previous hub cluster, where the backup was created, is shut down. If that cluster is running, the previous hub cluster tries to reimport the managed clusters when the managed cluster reconciliation finds that the managed clusters are no longer available.
   Should be : 
   Before restoring activation data on the passive hub
   , make sure that the previous hub cluster, where the backup was created, is shut down. If that cluster is running, the previous hub cluster tries to reimport the managed clusters when the managed cluster reconciliation finds that the managed clusters are no longer available.
2. It's very hard to find; I was in a call with a customer and could not find even if I contributed to the content .. 
   This link is only used here

1.1.4.1. Preparing clusters before restoring activation data

Before restoring activation data on the new hub cluster, complete the following steps to avoid data corruption or cluster loss:

1. Shut down the primary cluster.

See Shutting down the primary cluster for more information.

But See Shutting down the primary cluster  .. is not a link , so I had to copy paste the Shutting down the primary cluster and look for it in the doc. There is no reason for somebody to do this unless they already know what they are looking for

I propose to remove that link and put the content under the 1. Shut down the primary cluster. directly

Or even better .. keep the link and properly link it from the See Shutting down the primary cluster for more information.