feat(concepts): update backup docs (#3572)

* feat(concepts): update backup docs

* fix(versioned): update api tools link

docs/components/concepts/backups.md

@@ -20,12 +20,6 @@ Exercise caution when deleting clusters to avoid unintended loss of backups.
 
 > Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
 
-## Backup types
-
-### Manual backup
-
-Manual backups refer to the user-initiated process of creating a consistent snapshot of the state of all system components, including Zeebe, Operate, Tasklist, and Optimize. These backups are managed on a per-cluster basis and are primarily designed for disaster recovery purposes.
-
 ## Backup location
 
 When you create a cluster in Camunda 8 SaaS, you must specify a region for that cluster.
@@ -35,23 +29,24 @@ You also need to specify where the backups for that cluster will be located:
 - By default, the backups will be located in the same region as the cluster.
 - For disaster recovery reasons, you can select a "dual region" backup location. Backups will be automatically replicated in the secondary region to give you better protection in case the primary region experiences disruption. Dual region backup is offered at no additional cost.
 
-#### Backup limits and rate limits
+## Manual backup
 
-Each cluster has a limit of three manual backups. To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours.
+Manual backups refer to the user-initiated process of creating a consistent snapshot of the state of all system components, including Zeebe, Operate, Tasklist, and Optimize. These backups are managed on a per-cluster basis and are primarily designed for disaster recovery purposes.
+
+### Retention and rate limits
+
+To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours.
 However, users can delete an existing backup to create a new one before the rate limit period ends.
 
 The system retains the three most recent completed backups per cluster. Failed backup attempts do not count towards the retention count. When a new backup is successful and the retention count is reached, the oldest backup is automatically deleted.
 
-### Scheduled backups
+## Scheduled backups
 
 Scheduled backups are created periodically (e.g daily, weekly). They are configured to run automatically on the scheduled time.
 
-#### Backup limits and rate limits
-
-A backup schedule retains the last three successful and failed backups. Failed backups are retained to allow further root-causing why the backup failed.
+### Retention
 
-The system retains the three most recent successful/failed backups per cluster.
-If a backup fails, it's not retried immediately as the system waits for the next backup attempt.
+A backup schedule retains the last three successful and failed backups. Failed backups are retained to allow further root-causing why the backup failed. If a backup fails, it is not retried immediately as the failure can lead to instability.
 
 :::note
 If you require more retained backups or more frequent backups, contact your Customer Success Manager to discuss your specific needs.

versioned_docs/version-8.2/components/concepts/backups.md

@@ -8,39 +8,56 @@ description: "Learn more about Backups in Camunda 8 SaaS."
 
 You can use the backup feature of Camunda 8 SaaS to regularly back up the state of all of its components (Zeebe, Operate, Tasklist, and Optimize) with _zero downtime_. In case of failures that lead to data loss, you can request to restore the backup.
 
-A backup of Camunda 8 SaaS consists of a backup of Zeebe, Operate, Tasklist, Optimize, and the backup of exported Zeebe records in Elasticsearch. Since the data of these applications are dependent on each other, it is important that the backup is consistent across all components. Therefore, the backup of a Camunda 8 Cluster is taken as a whole.
+A Camunda 8 SaaS backup consists of a data backup of Zeebe, Operate, Tasklist, Optimize, and the backup of exported Zeebe records in Elasticsearch. Since the data of these applications depend on each other, the backup must be consistent across all components. Therefore, the backup of a Camunda 8 cluster is taken as a whole.
 
-With backups, you can capture snapshots of your data and applications while they are actively in use, resulting in zero downtime or disruption to your operations. Backups are designed specifically for disaster recovery purposes. Backups should not be used for archival of process data.
-
-## Backup and cluster relationship
+With backups, you can capture snapshots of your data and applications while they are actively in use, resulting in zero downtime or disruption to your operations. Backups are designed specifically for disaster recovery purposes, and should not be used for archival of process data.
 
+:::caution
 Backups are created and managed on a per-cluster basis. It is important to be aware that deleting a cluster will also delete all associated backups.
 
-:::caution
 Exercise caution when deleting clusters to avoid unintended loss of backups.
 :::
 
-Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
+> Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
+
+## Backup location
+
+When you create a cluster in Camunda 8 SaaS, you must specify a region for that cluster.
+
+You also need to specify where the backups for that cluster will be located:
+
+- By default, the backups will be located in the same region as the cluster.
+- For disaster recovery reasons, you can select a "dual region" backup location. Backups will be automatically replicated in the secondary region to give you better protection in case the primary region experiences disruption. Dual region backup is offered at no additional cost.
+
+## Manual backup
 
-## Rate limits
+Manual backups refer to the user-initiated process of creating a consistent snapshot of the state of all system components, including Zeebe, Operate, Tasklist, and Optimize. These backups are managed on a per-cluster basis and are primarily designed for disaster recovery purposes.
 
-Each cluster has a limit of three backups. To ensure system stability backup operations are subject to rate limits. Specifically, you can perform a backup operation every 5 hours. However, it is possible to delete a backup and create a new one before the 5-hour rate limit expires.
+### Retention and rate limits
 
-The system retains the three most recent completed backups per cluster. Failed backup attempts do not count towards the retention count. When a new backup is successful and the retention count is reached, the oldest backup will be automatically deleted.
+To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours.
+However, users can delete an existing backup to create a new one before the rate limit period ends.
+
+The system retains the three most recent completed backups per cluster. Failed backup attempts do not count towards the retention count. When a new backup is successful and the retention count is reached, the oldest backup is automatically deleted.
+
+## Scheduled backups
+
+Scheduled backups are created periodically (e.g daily, weekly). They are configured to run automatically on the scheduled time.
+
+### Retention
+
+A backup schedule retains the last three successful and failed backups. Failed backups are retained to allow further root-causing why the backup failed. If a backup fails, it is not retried immediately as the failure can lead to instability.
 
 :::note
-If you require more retained backups or more frequent backups, get in touch with your Customer Success Manager to discuss your specific needs.
+If you require more retained backups or more frequent backups, contact your Customer Success Manager to discuss your specific needs.
 :::
 
 ## Programmatic access
 
-The backup operations can be performed programmatically using the Administration API. This provides the flexibility to seamlessly integrate backup-related tasks with your existing systems and automation workflows. For detailed information on using the API, please refer to the [Administration API reference](/apis-tools/administration-api-reference.md/).
+The backup operations can be performed programmatically using the Administration API.
+This provides the flexibility to seamlessly integrate backup-related tasks with your existing systems and automation workflows.
+For detailed information on using the API, refer to the [Administration API reference](/docs/apis-tools/administration-api/administration-api-reference.md).
 
 ## Restore
 
-If you need to restore your Camunda 8 cluster from a backup, please follow these steps:
-
-1. [Contact Camunda support](https://camunda.com/services/support/) to request a restore for your backup.
-2. Our support team will assist you with the restoration process and guide you through the necessary steps to recover your cluster from the backup.
-
-For any further assistance or questions related to backups or restorations, please feel free to reach out to our support team.
+To restore your Camunda 8 cluster from a backup (and for any further assistance in general), [contact Camunda support](https://camunda.com/services/support/) to request a restore for your backup. Our support team will assist you with the restoration process and guide you through the necessary steps to recover your cluster from the backup.

versioned_docs/version-8.3/components/concepts/backups.md

@@ -12,29 +12,51 @@ A Camunda 8 SaaS backup consists of a data backup of Zeebe, Operate, Tasklist, O
 
 With backups, you can capture snapshots of your data and applications while they are actively in use, resulting in zero downtime or disruption to your operations. Backups are designed specifically for disaster recovery purposes, and should not be used for archival of process data.
 
-## Backup and cluster relationship
-
+:::caution
 Backups are created and managed on a per-cluster basis. It is important to be aware that deleting a cluster will also delete all associated backups.
 
-:::caution
 Exercise caution when deleting clusters to avoid unintended loss of backups.
 :::
 
-Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
+> Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
+
+## Backup location
+
+When you create a cluster in Camunda 8 SaaS, you must specify a region for that cluster.
+
+You also need to specify where the backups for that cluster will be located:
+
+- By default, the backups will be located in the same region as the cluster.
+- For disaster recovery reasons, you can select a "dual region" backup location. Backups will be automatically replicated in the secondary region to give you better protection in case the primary region experiences disruption. Dual region backup is offered at no additional cost.
 
-## Rate limits
+## Manual backup
 
-Each cluster has a limit of three backups. To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours. However, it is possible to delete a backup and create a new one before the 5-hour rate limit expires.
+Manual backups refer to the user-initiated process of creating a consistent snapshot of the state of all system components, including Zeebe, Operate, Tasklist, and Optimize. These backups are managed on a per-cluster basis and are primarily designed for disaster recovery purposes.
+
+### Retention and rate limits
+
+To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours.
+However, users can delete an existing backup to create a new one before the rate limit period ends.
 
 The system retains the three most recent completed backups per cluster. Failed backup attempts do not count towards the retention count. When a new backup is successful and the retention count is reached, the oldest backup is automatically deleted.
 
+## Scheduled backups
+
+Scheduled backups are created periodically (e.g daily, weekly). They are configured to run automatically on the scheduled time.
+
+### Retention
+
+A backup schedule retains the last three successful and failed backups. Failed backups are retained to allow further root-causing why the backup failed. If a backup fails, it is not retried immediately as the failure can lead to instability.
+
 :::note
 If you require more retained backups or more frequent backups, contact your Customer Success Manager to discuss your specific needs.
 :::
 
 ## Programmatic access
 
-The backup operations can be performed programmatically using the Administration API. This provides the flexibility to seamlessly integrate backup-related tasks with your existing systems and automation workflows. For detailed information on using the API, refer to the [Administration API reference](/apis-tools/administration-api-reference.md).
+The backup operations can be performed programmatically using the Administration API.
+This provides the flexibility to seamlessly integrate backup-related tasks with your existing systems and automation workflows.
+For detailed information on using the API, refer to the [Administration API reference](/docs/apis-tools/administration-api/administration-api-reference.md).
 
 ## Restore
 

versioned_docs/version-8.4/components/concepts/backups.md

@@ -12,29 +12,51 @@ A Camunda 8 SaaS backup consists of a data backup of Zeebe, Operate, Tasklist, O
 
 With backups, you can capture snapshots of your data and applications while they are actively in use, resulting in zero downtime or disruption to your operations. Backups are designed specifically for disaster recovery purposes, and should not be used for archival of process data.
 
-## Backup and cluster relationship
-
+:::caution
 Backups are created and managed on a per-cluster basis. It is important to be aware that deleting a cluster will also delete all associated backups.
 
-:::caution
 Exercise caution when deleting clusters to avoid unintended loss of backups.
 :::
 
-Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
+> Your cluster generation needs to be greater or equal to `8.2.4` to support backups.
+
+## Backup location
+
+When you create a cluster in Camunda 8 SaaS, you must specify a region for that cluster.
+
+You also need to specify where the backups for that cluster will be located:
+
+- By default, the backups will be located in the same region as the cluster.
+- For disaster recovery reasons, you can select a "dual region" backup location. Backups will be automatically replicated in the secondary region to give you better protection in case the primary region experiences disruption. Dual region backup is offered at no additional cost.
 
-## Rate limits
+## Manual backup
 
-Each cluster has a limit of three backups. To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours. However, it is possible to delete a backup and create a new one before the 5-hour rate limit expires.
+Manual backups refer to the user-initiated process of creating a consistent snapshot of the state of all system components, including Zeebe, Operate, Tasklist, and Optimize. These backups are managed on a per-cluster basis and are primarily designed for disaster recovery purposes.
+
+### Retention and rate limits
+
+To ensure system stability, backup operations are subject to rate limits. Specifically, you can perform a backup operation every five hours.
+However, users can delete an existing backup to create a new one before the rate limit period ends.
 
 The system retains the three most recent completed backups per cluster. Failed backup attempts do not count towards the retention count. When a new backup is successful and the retention count is reached, the oldest backup is automatically deleted.
 
+## Scheduled backups
+
+Scheduled backups are created periodically (e.g daily, weekly). They are configured to run automatically on the scheduled time.
+
+### Retention
+
+A backup schedule retains the last three successful and failed backups. Failed backups are retained to allow further root-causing why the backup failed. If a backup fails, it is not retried immediately as the failure can lead to instability.
+
 :::note
 If you require more retained backups or more frequent backups, contact your Customer Success Manager to discuss your specific needs.
 :::
 
 ## Programmatic access
 
-The backup operations can be performed programmatically using the Administration API. This provides the flexibility to seamlessly integrate backup-related tasks with your existing systems and automation workflows. For detailed information on using the API, refer to the [Administration API reference](/apis-tools/administration-api/administration-api-reference.md).
+The backup operations can be performed programmatically using the Administration API.
+This provides the flexibility to seamlessly integrate backup-related tasks with your existing systems and automation workflows.
+For detailed information on using the API, refer to the [Administration API reference](/docs/apis-tools/administration-api/administration-api-reference.md).
 
 ## Restore