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.

• [ ] 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.

Please add the following known issue content to ACM 2.8 ( it was already added to 2.9 , 2.10, 2.11 using https://github.com/stolostron/rhacm-docs/pull/6603)

Add to https://github.com/stolostron/rhacm-docs/blob/2.10_stage/release_notes/known_issues_continuity.adoc

Title : 

Bare metal hub resource no longer being backed up by the managed clusters backup

Description:
If the resources for the bare metal cluster are backed up and restored to a secondary hub cluster by using the {product-title-short} back up and restore feature, the managed cluster reinstalls on the nodes, which destroys the existing managed cluster.
Note: This only affects bare metal clusters that were deployed by using zero touch provisioning, meaning that they have BareMetalHost resources that manage powering on and off bare metal nodes and attaching virtual media for booting. If a BareMetalHost resource was not used in the deployment of the managed cluster, there is no negative impact.
 

To work around this issue, the managed BareMetalHost resources on the primary hub cluster are no longer backed up with the managed cluster backup. 

If you have a usecase different than the above and you want the managed BareMetalHost resources on the primary hub cluster to be backed up, add the backup label to the BareMetalHost resources on the primary hub cluster: cluster.open-cluster-management.io/backup.

Read this section to learn about using this backup label to backup generic resources. https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.8/html/business_continuity/business-cont-overview#resources-that-are-backed-up