From 7a907dae4443d22b6b92ffafdec2ca5da755381f Mon Sep 17 00:00:00 2001 From: jc-berger <> Date: Thu, 5 Dec 2024 12:44:32 -0500 Subject: [PATCH] changed anchor to troubleshoot build error --- business_continuity/backup_restore/backup_validate.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/business_continuity/backup_restore/backup_validate.adoc b/business_continuity/backup_restore/backup_validate.adoc index 30a522c6e9..0f68045cb0 100644 --- a/business_continuity/backup_restore/backup_validate.adoc +++ b/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.