Merge pull request #7302 from stolostron/swope-build

Build errors and coding in header Backup book

business_continuity/backup_restore/backup_validate.adoc

@@ -36,13 +36,13 @@ The following templates check the pod status for the backup component and depend
 +
 * `backup-storage-location-available` template checks if a `BackupStorageLocation.velero.io` resource is created and if the status value is `Available`. This implies that the connection to the backup storage is valid. 
 
-- *BackupSchedule collision validation*
+- *`BackupSchedule` collision validation*
 +
 * `acm-backup-clusters-collision-report` template verifies that the status is not `BackupCollision`, if a `BackupSchedule.cluster.open-cluster-management.io` exists on the current hub cluster. This verifies that the current hub cluster is not in collision with any other hub cluster when you write backup data to the storage location.
 +
-For a definition of the `BackupCollision`, see xref:../backup_restore/backup_schedule.adoc#avoid-backup-collision[Avoiding backup collisions].
+For a definition of the `BackupCollision`, see xref:../backup_restore/backup_schedule.adoc#prevent-backup-collision[Preventing backup collisions].
 
-- *BackupSchedule and restore status validation*
+- *`BackupSchedule` and restore status validation*
 +
 * `acm-backup-phase-validation` template checks that the status is not in `Failed`, or `Empty` state, if a `BackupSchedule.cluster.open-cluster-management.io` exists on the current cluster. This ensures that if this cluster is the primary hub cluster and is generating backups, the `BackupSchedule.cluster.open-cluster-management.io` status is healthy.
 * The same template checks that the status is not in a `Failed`, or `Empty` state, if a `Restore.cluster.open-cluster-management.io` exists on the current cluster. This ensures that if this cluster is the secondary hub cluster and is restoring backups, the `Restore.cluster.open-cluster-management.io` status is healthy.

release_notes/acm_whats_new.adoc

@@ -118,7 +118,7 @@ See link:../governance/grc_intro.adoc#governance[Governance] to learn more about
 
 * You can now customize the OADP version by setting an annotation on your `MultiClusterHub` resource. See link:../business_continuity/backup_restore/backup_install.adoc#installing-custom-oadp[Installing a custom OADP version].
 
-* You can now temporarily pause the `BackupSchedule` resource instead of deleting it. By using the `BackupSchedule` `paused` property on the backup hub cluster, you can avoid a backup collision. See link:../business_continuity/backup_restore/backup_schedule.adoc#avoid-backup-collision[Avoiding backup collisions].
+* You can now temporarily pause the `BackupSchedule` resource instead of deleting it. By using the `BackupSchedule` `paused` property on the backup hub cluster, you can avoid a backup collision. See link:../business_continuity/backup_restore/backup_schedule.adoc#prevent-backup-collision[Preventing backup collisions].
 
 * You can now keep the primary hub cluster active during a restore operation. See link:../business_continuity/backup_restore/backup_active_restore.adoc#keep-hub-active-restore[Keeping the primary hub cluster active during a restore process].