We created backup ID via /actuator/backups API (completed successfully on all 3 partitions), then restored using separate Kubernetes jobs per node, all showing “Successfully restored broker from backup”. Verification confirms raft data contains expected correlation IDs and the cluster is healthy with no errors.After successfully restoring a 3-node Zeebe 8.5.16 cluster from S3 backup using Kubernetes jobs, existing process instances are not “active” despite correlation IDs being present in the restored raft data. The cluster appears healthy and new process instances work correctly, but pre-existing process instances don’t respond to message correlations or execute tasks when expected inputs are sent.Has anyone encountered process instances becoming dormant after backup restoration? Do restored process instances need additional steps beyond raft data restoration to reactivate, or could this be related to partition leadership, timing requirements between node restores, or missing validation steps we should perform?
@Pratyusha28 Before restoring the backups, all the indices data need to be cleaned up. Also services (Optimize, Operate, Tasklist, Zeebe Broker, Zeebe GW) should be scaled to 0 replicas while restoration.
@aravindhrs Thank you for your response. we tried this and the BPMNs are now no longer dormant. But we had to restart Zeebe Broker, Zeebe GW for the cluster to get to good state. Wanted to check if a restart is required after restore ?
After restoration only you need to bring up the pods.