docs: standalone backup - code review

versioned_docs/version-8.6/self-managed/concepts/elasticsearch-without-cluster-privileges.md

@@ -1,8 +1,11 @@
 ---
 id: elasticsearch-without-cluster-privileges
 title: "Elasticsearch without cluster privileges"
+keywords: ["elasticsearch", "schema", "backup", "backups"]
 ---
 
+## Standalone Schema Manager
+
 If the Camunda single application cannot access Elasticsearch with cluster-level privileges, it is possible to run the schema manager as a standalone application separate from the main application.
 
 In this case, cluster privileges are only required for the schema creation, the single application does not need cluster privileges to work.
@@ -15,7 +18,7 @@ This feature is only available from version 8.6.10 onwards and is also only supp
 An index-level privilege of at least `manage` is still required for the Camunda single application to work properly.
 :::
 
-## Setup
+### Setup
 
 For this setup to work:
 
@@ -24,7 +27,7 @@ For this setup to work:
 
 The steps are described in detail below.
 
-### 1. Initialize the Schema Manager
+#### 1. Initialize the Schema Manager
 
 The schema manager is started as a separate standalone Java application and is responsible for creating and managing the database schema and applying database settings, such as retention policies for example.
 
@@ -79,7 +82,7 @@ SPRING_CONFIG_ADDITIONALLOCATION=/path/to/schema-manager.yaml ./bin/schema
 
 Verify that the application executed successfully.
 
-### 2. Start the Camunda single application
+#### 2. Start the Camunda single application
 
 The Camunda single application can now be started without cluster-level privileges. The application will connect to the database and use the schema created by the schema manager.
 
@@ -284,8 +287,106 @@ operate:
     [...] # Any other custom config.
 ```
 
-## Limitations
+### Limitations
 
 - This feature is only available for the Camunda `8.6.10` version and above.
 - This feature only works for installations using Elasticsearch.
 - Camunda Optimize cannot be executed with this setup.
+
+## Standalone Backup application
+
+Creating backup snapshot in Elasticsearch requires `manage_snapshots` cluster-level privileges. If the Camunda application(s) cannot access Elasticsearch with cluster-level privileges, it is possible to run the backup Operate and Tasklist data as a standalone application separate from the main application.
+
+In this case, cluster privileges are only required for the backup creation, the Camunda application(s) do not need cluster privileges to work.
+
+:::note Database Support
+This feature is only available from version 8.6.12 onwards and is also only supported for Elasticsearch installations (no OpenSearch support).
+:::
+
+:::note
+This standalone application only takes care of Operate and Tasklist indices; Optimize is not part of this procedure.
+:::
+
+The steps are described in detail below.
+
+### Setup
+
+Before you can use the standalone backup manager, you need
+
+- A user with cluster-level privileges, which includes the creation of snapshots, must be configured in Elasticsearch. A user with [snapshot_user](https://www.elastic.co/guide/en/elasticsearch/reference/current/built-in-roles.html#:~:text=related%20to%20rollups.-,snapshot_user,-Grants%20the%20necessary) role should be enough to run the backup applications. However, when restoring snapshots, index-level permissions are needed to restore data.
+- An [Elasticsearch snapshot repository](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshot-restore.html) must be configured.
+
+#### 1. Configure the Backup application
+
+Create an custom configuration `backup-manager.yaml` file for the backup standalone application with the following values:
+
+```
+camunda:
+  operate:
+    backup:
+      # Example assuming an existing snapshot repository 'els-test'
+      repositoryName: els-test
+    elasticsearch:
+      # Example assuming an existing user called 'camunda-admin' who has 'snapshot_user' privileges
+      username: camunda-admin
+      password: camunda123
+      healthCheckEnabled: false
+  tasklist:
+    backup:
+      # Example assuming an existing snapshot repository 'els-test'
+      repositoryName: els-test
+    elasticsearch:
+      # Example assuming an existing user called 'camunda-admin' who has 'snapshot_user' privileges
+      username: camunda-admin
+      password: camunda123
+      healthCheckEnabled: false
+
+```
+
+#### 2. Start the Backup application
+
+Start the Java application `backup-webapps` (or `backup-webapps.bat` for Windows) provided in the `bin` folder of the delivered jar file. It takes `<backupID>` as argument. The `<backupID>` is the unique identifier of the backup, used as part of the snapshot names. You can find more details about this in [Backup and restore](/self-managed/operational-guides/backup-restore/backup-and-restore.md).
+
+Assuming the configuration above was saved in a file named `backup-manager.yaml`, you can start the application with the following command:
+
+```
+SPRING_CONFIG_ADDITIONALLOCATION=/path/to/backup-manager.yaml ./bin/backup-webapps <backupID>
+```
+
+The standalone application will log the current state of the backup, every 5 seconds, until it completes.
+
+Verify that the application executed successfully. Example output logs:
+
+```
+INFO  io.camunda.application.StandaloneBackupManager - Snapshot observation:
+INFO  io.camunda.application.StandaloneBackupManager - Operate indices snapshot is COMPLETED. Details: [GetBackupStateResponseDto{backupId=12345, state=COMPLETED, failureReason='null', details=[GetBackupStateResponseDetailDto{snapshotName='camunda_operate_12345_8.6.11-snapshot_part_1_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.016+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_operate_12345_8.6.11-snapshot_part_2_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.216+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_operate_12345_8.6.11-snapshot_part_3_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.216+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_operate_12345_8.6.11-snapshot_part_4_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.416+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_operate_12345_8.6.11-snapshot_part_5_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.617+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_operate_12345_8.6.11-snapshot_part_6_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.617+01:00, failures=[]}]}]
+INFO  io.camunda.application.StandaloneBackupManager - Tasklist indices snapshot is COMPLETED. Details: [GetBackupStateResponseDto{backupId=12345, state=COMPLETED, failureReason='null', details=[GetBackupStateResponseDetailDto{snapshotName='camunda_tasklist_12345_8.6.11-snapshot_part_1_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.016+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_tasklist_12345_8.6.11-snapshot_part_2_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.216+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_tasklist_12345_8.6.11-snapshot_part_3_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.416+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_tasklist_12345_8.6.11-snapshot_part_4_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.416+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_tasklist_12345_8.6.11-snapshot_part_5_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.617+01:00, failures=[]}, GetBackupStateResponseDetailDto{snapshotName='camunda_tasklist_12345_8.6.11-snapshot_part_6_of_6', state='SUCCESS', startTime=2025-03-11T17:49:08.818+01:00, failures=[]}]}]
+INFO  io.camunda.application.StandaloneBackupManager - Backup with id:[12345] is completed!
+```
+
+The backup manager will create a backup of Operate and Tasklist data. The backup includes several
+Elasticsearch snapshots containing sets of Operate and Tasklist indices. For example, a backup with an ID of `123` may contain the following Elasticsearch snapshots:
+
+```
+camunda_operate_123_8.6.0_part_1_of_6
+camunda_operate_123_8.6.0_part_2_of_6
+camunda_operate_123_8.6.0_part_3_of_6
+camunda_operate_123_8.6.0_part_4_of_6
+camunda_operate_123_8.6.0_part_5_of_6
+camunda_operate_123_8.6.0_part_6_of_6
+camunda_tasklist_123_8.6.0_part_1_of_6
+camunda_tasklist_123_8.6.0_part_2_of_6
+camunda_tasklist_123_8.6.0_part_3_of_6
+camunda_tasklist_123_8.6.0_part_4_of_6
+camunda_tasklist_123_8.6.0_part_5_of_6
+camunda_tasklist_123_8.6.0_part_6_of_6
+```
+
+Once completed, you can proceed with step 7 of the [backup procedure](self-managed/operational-guides/backup-restore/backup-and-restore.md#backup-process).
+
+### Limitations
+
+- This feature is only available for the Camunda `8.6.12` version and above.
+- This feature only works for installations using Elasticsearch.
+- Camunda Optimize data cannot be backed up with this setup.
+- TODO add getBackup and deleteBackup

versioned_docs/version-8.6/self-managed/operational-guides/backup-restore/backup-and-restore.md

@@ -5,6 +5,9 @@ sidebar_label: "Backup and restore"
 keywords: ["backup", "backups"]
 ---
 
+:::note
+If the Camunda application(s) cannot access Elasticsearch with cluster-level privileges, it is possible to run the backup of Operate and Tasklist indices (steps 2, 3, 5 and 6 from the backup procedure below) as a standalone application separate from the main application (see [Standalone Backup application](/self-managed/concepts/elasticsearch-without-cluster-privileges.md#Standalone Backup application)).
+:::
 :::note
 This release introduces breaking changes for [Operate and Tasklist](./operate-tasklist-backup.md), as well as [Optimize](./optimize-backup.md).
 :::
@@ -62,10 +65,6 @@ By default, the indices are prefixed with `zeebe-record`. If you have configured
 If any of the steps above fail, you may have to restart with a new backup id. Ensure exporting is resumed if the backup process force quits in the middle of the process.
 :::
 
-:::note
-If the Camunda application(s) cannot access Elasticsearch with cluster-level privileges, it is possible to run the backup of Operate and Tasklist indices (steps 2, 3, 5 and 6) as a standalone application separate from the main application (see [Backup and restore Operate and Tasklist data without cluster privileges](/self-managed/operational-guides/backup-restore/operate-tasklist-backup-without-cluster-privileges.md)).
-:::
-
 ### Restore
 
 To restore a Camunda 8 cluster from a backup, all components must be restored from their backup corresponding to the same backup id:

versioned_sidebars/version-8.6-sidebars.json

@@ -1886,7 +1886,6 @@
           "items": [
             "self-managed/operational-guides/backup-restore/optimize-backup",
             "self-managed/operational-guides/backup-restore/operate-tasklist-backup",
-            "self-managed/operational-guides/backup-restore/operate-tasklist-backup-without-cluster-privileges",
             "self-managed/operational-guides/backup-restore/zeebe-backup-and-restore",
             "self-managed/operational-guides/backup-restore/modeler-backup-and-restore"
           ]