Camunda backup creation (RDBMS)

Back up your Camunda 8 Self-Managed components and cluster when using a relational database management system (RDBMS) as secondary storage.

Prerequisites

The following prerequisites are required before you can create a backup.

Prerequisite	Description
Configure Zeebe backup storage.	Configure the backup storage for Zeebe. This is required regardless of your secondary storage choice. See Zeebe backup configuration.
Enable continuous backups	Enable continuous backups. See Zeebe scheduler configuration.
(Recommended) Configure Zeebe scheduled backup.	Configure Zeebe's internal primary storage backup scheduler. See Zeebe scheduler configuration.

Considerations

When Camunda uses an RDBMS as secondary storage, backups and restores involve two independent systems:

• Zeebe (primary storage)
• The external RDBMS used for secondary storage

tip

While Zeebe during restore will match the secondary's storage backup position, it is recommended to have the backups taken at similar intervals. This minimizes the time required after restore for Zeebe to re-export the events to the secondary storage.

Back up process

Scheduled backup

With Zeebe being set up against an RDBMS secondary storage, you have the option to enable Zeebe's internal backup scheduler. Enabling the scheduler will result in primary storage backups being created at the predefined interval. Learn more about configuring the backup scheduler here.

In addition to the scheduler, continuous primary storage backups must be enabled by setting camunda.data.primary-storage.backup.continous to true. With continuous backups enabled, log stream compaction is bound by the latest backed up position. In turn, this means that no segment of Zeebe's state can be deleted without being backed up first.

These two options provide a strong guarantee for the resiliency of your data and provide you the ability to always maintain an active window that you can restore to as a disaster recovery scenario.

tip

You can still request on-demand primary storage backups through the regular API, without the backupId parameter as it's being generated by the cluster.

warning

To properly configure your backup interval consult the metrics provided regarding your average take backup latency. As a general rule of thumb, the backup interval must be greater than your latency. Latency is affected by the size of Zeebe's runtime state.

Manual backup

If you opt out of the scheduled backup approach, you can still request on-demand backups using the backup management API.

# Define the backup ID, we recommend using unix timestamps.
export BACKUP_ID=$(date +%s)

# For Kubernetes port-forwarding, set the following endpoints:
export ORCHESTRATION_CLUSTER_MANAGEMENT_API=http://localhost:9600

curl -X POST "$ORCHESTRATION_CLUSTER_MANAGEMENT_API/actuator/backupRuntime" \
  -H "Content-Type: application/json" \
  -d "{\"backupId\": $BACKUP_ID}"

tip

It is recommended to have primary storage backup taken after the secondary storage one, if you are coordinating the backup process.

note

If continuous backups are enabled, the backupId parameter must be omitted.

(Optional) Back up Web Modeler data

If you are using Web Modeler, you can also back up its data. Web Modeler stores its data in a relational database, so you can use the same backup tools as for the RDBMS secondary storage.

See backup and restore Web Modeler data for more details.

Primary storage retention

With Camunda 8.9 you now have the option to enable a retention mechanism over primary storage (Zeebe's) backups. This will periodically delete backups from the configured blob storage based on the preconfigured retention window. Learn more about configuring backup retention here. The retention mechanism will always maintain one backup regardless of the window configuration, this is a data resiliency measure.

note

This only affects the primary storage.