Your cluster is gone. A storage volume failed, a Helm command ran in the wrong namespace, or a bad migration corrupted state across all partitions. The cause matters less than what happens next: the clock is running against a recovery time objective someone wrote into a document, and you're about to find out whether that number was real.
Camunda 8.10 Self-Managed changes how those hours look. Restore is a cluster operation you call through the API. No broker restarts, no deployment changes, no working through nodes one at a time.
What cluster restore used to cost
Until now, recovery meant running a standalone restore application that was shipped with the broker image. You stopped the brokers, set environment variables on each one, cleared data directories by hand, ran the restore application, then brought the cluster back up and checked whether the state was consistent.
Every step was a deployment change, so none of it could be expressed declaratively. It couldn't go into Terraform or run from a pipeline, and rehearsing it meant booking a day of someone's time.
That last point matters more than it looks. Most teams have a documented restore procedure. Far fewer have run one. A recovery plan nobody has executed isn't a plan; it's an estimate, and the difference only shows up on the worst day of the quarter.
Restore as a cluster operation
In-process restore runs through the Orchestration Cluster REST API in three steps.
- Put the cluster into recovery mode: PATCH /v2/mode?mode=RECOVERING Processing pauses. The brokers stay up.
- Restore your secondary storage, Elasticsearch, OpenSearch, or your relational database to the point you want to recover to.
- Trigger the restore: POST /v2/restore with the backup ID.
- Poll GET /v2/restore to watch partitions come back.
- Confirm health with GET /v2/topology.
Note where the point of no return sits. Recovery mode pauses processing; it deletes nothing. The destructive step is the restore call itself, which drops local partition data on every broker before writing the backup, and that can't be undone. Between step one and step two you still have a decision window, and pausing costs you nothing if the situation turns out to be recoverable another way.
What does this change for disaster recovery?
In-process restore replaces the manual, broker-by-broker procedure with a sequence of API calls. Because the whole thing now runs end-to-end through the API, you can measure your recovery time by actually running it rather than estimating it in a DR document.
The less obvious change is that restore becomes code. It's a sequence of authenticated API calls, so it lives wherever you already keep operational logic: a Terraform module, a Helm hook, a Kubernetes init container, a pipeline job. It gets reviewed, versioned, and changed like anything else you run in production. That makes rehearsal cheap enough to actually do. Add a scheduled job that restores last night's production backup to a throwaway cluster and verifies that the topology is healthy again. Run it quarterly, and your recovery time objective becomes a measurement instead of a target.
Consider what's at stake in that number. A Camunda cluster doesn't hold rows; it holds work in progress: orders halfway through fulfillment, claims waiting on approval, agents parked on a response that hasn't arrived. Zeebe keeps that state distributed across brokers, which is what lets those processes run for weeks. Brokers also form a peer-to-peer network with no single point of failure, so losing one node doesn’t stop the work. Losing the whole cluster does, and restore is how you get it back. A lost cluster isn’t a data problem you reconcile next week. It’s the end-to-end process your business is running right now.
What's not in scope
This release restores an entire cluster from backup or a single point in time. It can also restore a single tenant only without affecting other tenants. Partial and selective restore, restoring while the cluster keeps processing, and merging data across clusters aren't part of it. Full-cluster recovery covers the situations that actually take teams offline, and shipping a dependable version of that mattered more than covering every variant.
Try it: run a restore drill before you need one
Pick a date in the next quarter. Restore a production-sized backup into a cluster nobody depends on and time it end-to-end. Whatever number comes back is your actual recovery-time objective. If it holds up, put the script in your pipeline and stop estimating. If it doesn't, you've found the problem while it's still cheap to fix.
Orchestration keeps those processes coordinated, so a tested restore protects the work, not just the data.
Full details, including the multi-tenant endpoints and the storage-specific steps, are in the Backup and Restore documentation.
