Treat restore as an explicit destructive workflow.

Restore is modeled as OpenBaoRestore, an immutable request object that keeps disaster recovery visible, auditable, and separate from normal cluster reconciliation. Use this page to understand when restore is appropriate and what boundaries it enforces before you run it.

Decision matrix

Use restore when

Use restore when.

Situation	Why restore fits	Watch for
Disaster recovery	You need to reintroduce known-good state after severe corruption, cluster loss, or a failed repair path.	Restore overwrites the target cluster. Validate the snapshot and target before you start.
Environment cloning	You want to move a realistic snapshot of production state into staging or another controlled environment.	Be deliberate about secrets, tokens, and any sensitive data you are copying.
Migration between clusters or regions	The restore workflow gives you an explicit, auditable way to land snapshot state on a different target cluster.	The target cluster must already exist and the storage/auth path must work from that environment.
Ordinary troubleshooting	Restore is usually not the first move. Start with the incident recovery or troubleshooting guides first.	Do not overwrite state while a narrower repair path is still viable.

Diagram

Restore control flow

A restore request is validated, acquires the cluster operation lock, then launches a restore Job that pulls the snapshot and injects it into the target cluster. The workflow is explicit so destructive recovery does not hide inside normal reconciliation.

Reference table

What OpenBaoRestore guarantees

What OpenBaoRestore guarantees.

Contract	Why it exists
Explicit request object	Restore is visible and auditable instead of being hidden inside cluster status or imperative scripts.
Immutable spec	Changing restore intent requires a new request so the audit trail stays stable and the controller does not reinterpret a running job.
Operation lock ownership	Restore blocks conflicting upgrades and backups while destructive work is in flight.
Separate restore identity	The restore Job authenticates separately from the main workload so recovery credentials are deliberate rather than inherited accidentally.

Restore overwrites cluster state

Restore is not a read-only diagnostic step. It replaces the target cluster state with the contents of the selected snapshot and may still leave the cluster needing follow-up work such as unseal or Raft repair.

Minimal restore request

Configure

Create a minimal OpenBaoRestore request

yaml

apiVersion: openbao.org/v1alpha1
kind: OpenBaoRestore
metadata:
name: prod-restore
namespace: security
spec:
cluster: prod-cluster
source:
  target:
    provider: s3
    endpoint: https://s3.amazonaws.com
    bucket: openbao-backups
    region: us-east-1
    credentialsSecretRef:
      name: s3-credentials
  key: clusters/prod/backup-2026-03-20.snap
jwtAuthRole: openbao-operator-restore

The target OpenBaoCluster and the OpenBaoRestore request live in the same namespace. To change the restore intent later, create a new resource instead of editing the running one.

Continue with the restore path

Run a restoreUse the task page when you are ready to configure the source, auth path, and verification steps in full.Recover after upgrade restoreUse the override-lock runbook only when a failed upgrade blocks the normal restore workflow.Restore manager architectureSee how validation, operation locks, and restore job execution fit together inside the controller.