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 link 
https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.11/html/business_continuity/business-cont-overview#backup-validation-using-a-policy

This content is confusing , not clear what issue an error would flog

Change:

• Backups that actively run as a cron job

• A BackupSchedule.cluster.open-cluster-management.io actively runs and saves new backups at the storage location. This validation is done by the backup-schedule-cron-enabled policy template. The template checks that there is a Backup.velero.io with velero.io/schedule-name: acm-validation-policy-schedule label at the storage location.
• The acm-validation-policy-schedule backups are set to expire after the time is set for the backups cron schedule. If no cron job is running to create backups, the old acm-validation-policy-schedule backup is deleted because it expired and a new one is not created. As a result, if no acm-validation-policy-schedule backups exist at any moment, it means that there are no active cron jobs generating backups.
• This policy is intended to help notify the hub cluster administrator of any backup issues when the hub cluster is active and produces or restore backups.

With:

Backup schedules are generating backups on primary hub
 

• The policy template backup-schedule-cron-enabled is intended to help notify the hub cluster administrator that the primary hub cluster doesn't produce new backups. It points to issues with the BackupSchedule.cluster.open-cluster-management.io resource not being enabled on the primary hub cluster or not being able to produce scheduled backups.
• The policy template  backup-schedule-cron-enabled is in violation if the backup schedule on the primary hub had generated no new backups at the time expected from the BackupSchedule cron job definition. This could happen if the BackupSchedule doesn't exist, is Paused, or the BackupSchedule cron job property was updated and the time to run the backups was increased. The template will be in violation until a new set of Backups is created.
• How this template validation works:
  • A BackupSchedule.cluster.open-cluster-management.io actively runs and saves new backups at the storage location. This validation is done by the backup-schedule-cron-enabled policy template. The template checks that there is a Backup.velero.io with a velero.io/schedule-name: acm-validation-policy-schedule label at the storage location.
  • The acm-validation-policy-schedule backups are set to expire after the time is set for the backups cron schedule. If no cron job is running to create backups, the old acm-validation-policy-schedule backup is deleted because it expired and a new one is not created. As a result, if no acm-validation-policy-schedule backups exist at any one moment, it means that there are no active cron jobs generating backups.
• This policy is intended to help notify the hub cluster administrator of any backup issues when the hub cluster is active and produces or restore backups.
•