Prepare routine operations before you need an incident response. A supportable cluster has a proven snapshot and restore path, an upgrade policy, monitored conditions, and named owners for maintenance and recovery.
Choose a task
| Goal | Start here |
|---|---|
| Establish the production operating baseline | Review production readiness |
| Create and retain Raft snapshots | Back up a cluster |
| Change the OpenBao version | Upgrade a cluster |
| Drain, scale, restart, or pause a cluster | Run planned maintenance |
| Find the cause of a degraded service | Troubleshoot a cluster |
| Delete a cluster intentionally | Decommission a cluster |
| Repair a sealed cluster | Recover a sealed cluster |
| Repair leadership or quorum | Recover from no leader |
| Continue after a failed blue-green rollback | Recover a failed rollback |
| Reintroduce state from a snapshot | Restore a snapshot |
Start every incident with status
Status is the operator’s latest observation. Events show how it got there. Inspect both before changing the cluster.
inspect
Collect the first cluster signals
kubectl -n <namespace> get openbaocluster <name> -o yaml
kubectl -n <namespace> get pods,pvc,services
kubectl -n <namespace> get events --sort-by=.lastTimestampUse the condition reason and message, not only status.phase. See Status and events
for the observable contract.