Product, Releases

Automated Cluster Restore Comes to Camunda 8 SaaS

Camunda 8 SaaS Enterprise customers can now restore a cluster from a backup themselves, in Console or through the API. What a backup covers, how restore works, and what we scoped out.

By Andrey Belik

You can now restore a Camunda 8 SaaS cluster from a backup yourself, in Console or through the API. Choose a completed backup, confirm, and the cluster is restored to that point. The recovery path is yours to run.

Available for Camunda 8 SaaS Enterprise customers. Anyone with organization admin permissions for the target cluster can run it. The same operation is on the Administration API with the CreateHotBackups permission if you'd rather script it.

What a backup contains

A backup is a consistent snapshot of the entire cluster, not just a dump of a single database. It covers:

  • Zeebe data, including in-flight process instances
  • Operate and Tasklist data
  • Optimize data
  • Zeebe records exported to secondary storage

Camunda keeps your three most recent backups per category. These are built for recovery, not for archival. If you need to process data that has been retained for years, reach out to your Customer Success Manager. This gives you the same operational control over disaster recovery that Operate already gives you over live process visibility, built on Zeebe's distributed, no-single-point-of-failure architecture.

How to restore

  1. Open Console and select your organization.
  2. Go to the target cluster and open its Backups section.
  3. Find the backup you want and select Restore.
  4. Check the confirmation details: backup name, completion date, and version.
  5. If the backup was taken on a different version, acknowledge the compatibility warning.
  6. Select Restore to start.

The cluster moves to Restoring and returns to Healthy when it finishes.

What to know before you run it

Restore is destructive, and it happens in place. Read this list once now rather than during an incident.

  1. The restore overwrites current cluster data. Anything created after the backup point is gone.
  2. The cluster is unavailable for the duration. Cluster upgrades, encryption changes, and new backups are blocked while it runs.
  3. Only one restore runs at a time per cluster.
  4. Only completed backups created after this feature became available are eligible.

Recovery time depends on how much data your cluster stores and how long the backend takes to restore it. There’s no number that’s meaningful across every cluster, so measure it once so your runbook has the real figure.

What we have not done yet

A restore targets the same cluster, organization, and region. Cross-cluster, cross-region, and cross-organization restores aren't in this release.

That was a scoping decision. Same-cluster restore covers the cases we see most often in support and feature requests, and it was the fastest way to get the recovery path out of the ticket queue. Which of the remaining ones matters most depends on you. If cross-region is the one blocking your disaster recovery plan, vote for this feature on our Roadmap here, because that changes how we sequence the next step.

When would you use it?

Recovering from data corruption

After an incident leaves the cluster or your application data inconsistent, identify the last known-good backup, confirm it is marked as completed, and restore it. Then check in Operate that new process instances start cleanly and existing data reads as expected.

Rolling back a failed change

When a deployment or configuration change in your application stack causes serious problems, restore the backup from before the change and confirm your core processes and integrations work. Root cause analysis comes afterward, without the outage still running.

Running a disaster recovery test

This is the test that matters most. Pick a scope and success criteria, use your production runbook rather than a shortcut, and record the elapsed time and any blockers. It tests whether the runbook is any good, not only whether the platform can be restored. If nobody has ever run the procedure, you do not really know if it works.

Try it

Check if you hold organization admin permissions. Then run a restore on a non-critical cluster and time it, so your runbook carries a real number. Put the next test in the calendar while you are there.

Full details are in the docs: backup and restore overview.

Start the discussion at forum.camunda.io

Try All Features of Camunda