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/2.10/html/business_continuity/business-cont-overview#backup-validation-using-a-policy

Dev story: https://issues.redhat.com/browse/ACM-11855

The whole section `OADP channel validation` needs to be updated as follows:

• OADP validation:

When you enable the backup component on the MultiClusterHub, the cluster backup and restore operator Helm chart can automatically install the OADP operator in the open-cluster-management-backup namespace, or you can install it manually in that namespace. The OADP channel you select for manual installation must match or exceed the version set by the Red Hat Advanced Cluster Management backup and restore operator Helm chart. Since the OADP Operator and Velero Custom Resource Definitions (CRDs) are cluster-scoped, you cannot have multiple versions on the same cluster. You must install the same version in the open-cluster-management-backup namespace and any other namespaces.

The following templates check for availability and validate the OADP installation:

oadp-operator-exists: Verifies if the OADP operator is installed in the open-cluster-management-backup namespace.

oadp-channel-validation: Ensures the OADP operator version in the open-cluster-management-backup namespace matches or exceeds the version set by the Red Hat Advanced Cluster Management cluster backup and restore operator.

custom-oadp-channel-validation: Checks if OADP operators in other namespaces match the version in the open-cluster-management-backup namespace.

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: