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.

      - [x] New topic in an existing section or new section
      - [ ] 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:

Update this section 
https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html/business_continuity/business-cont-overview#avoid-backup-collision

Add a new item to the list starting with ( See the following list to learn about two scenarios that might cause a backup collision: ) 

3. The administrator tests a disaster scenario by making Hub2 a primary hub cluster, without stopping Hub1 first:

• Hub1 is still running.

• Hub1 backup data is restored on Hub2, including managed clusters backup. Hub2 is now the active cluster.

• Since the BackupSchedule.cluster.open-cluster-management.io resource is still enabled on Hub1, it writes backups at the same storage location and this corrupts the backup data. Any hub cluster restoring the latest backups from this location might use Hub1 data instead of Hub2 data.  To avoid data corruption, Hub1 BackupSchedule resource status changes automatically to BackupCollision.  In this scenario, stopping Hub1 first or deleting the BackupSchedule.cluster.open-cluster-management.io resource on Hub1 before restoring managed clusters data on  Hub2 avoids getting into this backup collision state.