-
Task
-
Resolution: Done
-
Undefined
-
ACM 2.12.0
-
False
-
None
-
False
-
-
-
None
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.
Parent task
https://issues.redhat.com/browse/ACM-13242
Change #1:
For the Table 1.3. BackupSchedule status table, add a new line
BackupSchedule status: Paused
Description: The user had paused the ACM backup schedule using the BackupSchedule.paused property. As a result, the Velero schedules created by the BackupSchedule resource are deleted and no new hub backups are generated. Updating the BackupSchedule.paused to false will change the BackupSchedule resource status back to Enabled and Velero schedules are recreated.
Change #2:
Link
Add the following before this sentence: ( See the following list to learn about two scenarios that might cause a backup collision: )
To avoid a backup collision when you run a restore operation in a controlled environment, such as a disaster recovery test operation, before restoring the resources on the new hub cluster, pause the BackupSchedule resource on the backup hub. You can do that by setting the paused=true property on the BackupSchedule resource.
Change #3 fyi jberger@redhat.com .. thanks !
Change in item 2, last bullet :
From
In this scenario, stopping Hub2 first or deleting the BackupSchedule.cluster.open-cluster-management.io resource on Hub2 before starting Hub1 fixes the backup collision issue.
To:
In this scenario, stopping Hub2 first or pausing the BackupSchedule.cluster.open-cluster-management.io resource on Hub2 before starting Hub1 fixes the backup collision issue.
- depends on
-
ACM-13364 [Doc. Verification] ACM-13263: document BackupSchedule paused property
- Closed