Use this lane to rehearse restore across a real cluster boundary before you trust a cloud DR pair.

This local DR baseline keeps the source, target, and shared trust services separated so backup, restore, unseal, and cutover all cross the same kinds of boundaries they will cross in a real disaster-recovery event.

Classification

Local disaster-recovery reference architecture. k3d is not the production target, but this lane is the proving ground for the DR invariants that matter before you move to a cloud recovery pair.

Decision matrix

Lane summary

Lane summary.

Surface	Choice	Why it matters
Cluster split	One infra cluster, one source cluster, one target cluster	Restore crosses a real cluster boundary instead of staying inside one namespace or one API server.
Seal path	Shared external Transit key	The target can only unseal restored data because it shares the same external seal root of trust as the source.
Transfer boundary	RustFS S3-compatible bucket	Snapshots move through a real object-storage boundary that both clusters can reach independently.
Edge model	Dedicated passthrough endpoints for infra, source, and target	The lane validates real ingress reachability without collapsing TLS termination into a single local shortcut.
Cutover model	Manual restore and manual client or DNS cutover	The lane proves restore correctness, not automatic failover orchestration.

Diagram

Validated lane topology

The source cluster writes snapshots to shared storage, the target cluster restores from that storage, and both sides depend on the same external Transit key to make restored data usable.

Why this lane exists

Reference table

Key design choices

Key design choices.

Choice	What it protects	Why it stays in the lane
Shared seal root	Restored data is still decryptable after it lands in the target cluster.	This is the core DR invariant. Without a shared external seal root, the target can restore bits and still fail to unseal.
Separate infra cluster for trust services	The shared Transit dependency stays independent from source and target failure domains.	The lane should treat trust services as an external dependency, not as part of either OpenBao cluster.
Shared RustFS bucket	The restore uses the same object-transfer shape as a real remote-storage path.	The lane is meant to prove the handoff through storage, not just a local disk copy.
Manual cutover	Operators verify the target before traffic moves.	The lane proves correctness and operator workflow, not automated failover policy.

Stay on the validated path

• keep the source and target on the same OpenBao version for the restore event
• keep the source and target pointed at the same Transit address, CA bundle, SNI, and key name
• keep shared object storage reachable from both clusters before you start a backup or restore
• keep the target cluster created ahead of time with restore auth configured
• perform cutover only after credential and data verification succeeds on the restored target

What this lane validated

The local DR lane proved source backup to RustFS, restore into a separate target cluster, target unseal with the shared Transit key, and post-restore checks that source credentials and source data replaced the target bootstrap state.

What this lane is not

This is not an automatic failover design, not a cloud DR reference, and not proof that any backup can restore into any target shape. It is a validated manual recovery lane with explicit preconditions.

Use the lane

Bootstrap recipeStand up the infra, source, and target clusters that make up the DR proving ground.DR restore runbookRun the destructive restore workflow and verify that source state replaced target state cleanly.Restore from backupReview the generic restore behavior behind the lane-specific runbook.