Disciplines · Decisions (ADRs)

ADR-0051: OSHUN Studio Backup and Disaster Recovery UX

Studio coordinates critical workflows across Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian.

Accepted · 2026-02-23
10sections4 minread
Markdown source
On this page

Status: Accepted
Date: 2026-02-23
Authors: OSHUN Studio Architecture, OSHUN Data Platform Engineering, OSHUN Web Engineering, OSHUN BFF Engineering, Platform SRE
Reviewers: Domain Leads (Yemaya, Isis, Hathor, Aja, Bellona), Project Obsidian Program Design, Security and Compliance

Context and Problem Statement#

Studio coordinates critical workflows across Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian. Cross-domain data and operational states now require deterministic backup, restore, and disaster-recovery visibility for operators.

Recovery actions currently rely on fragmented operational tooling and domain-specific playbooks. Without a first-class backup and disaster-recovery UX, Studio risks:

  • slow and inconsistent recovery execution during incidents
  • unclear blast-radius and recovery-point visibility for operators
  • weak governance evidence for backup/restore decisions
  • higher chance of unsafe restores or incomplete state reconciliation

Decision Drivers#

  • Operational resilience: recovery paths must be deterministic and fast.
  • Safety: restore workflows must preserve state integrity and guardrails.
  • Traceability: every backup/restore action requires auditable evidence.
  • Consistency: one cross-domain UX model for recovery orchestration.
  • Scalability: support increasing project count and recovery complexity.

Considered Options#

Option 1: Infrastructure-Only Recovery Tooling#

Keep recovery orchestration in infrastructure/operator tools without Studio UX.

Pros:

  • Lower immediate Studio implementation overhead.

Cons:

  • Poor workflow visibility for Studio operators.
  • Weak cross-domain governance and evidence continuity.

Option 2: Domain-Specific Recovery Screens#

Each domain provides local backup and disaster-recovery interfaces.

Pros:

  • Domain customization flexibility.

Cons:

  • Fragmented operator experience and uneven safety guardrails.
  • Harder to coordinate cross-domain recovery scenarios.

Option 3: Canonical Studio Backup and Disaster Recovery UX (Chosen)#

Adopt one Studio UX contract for backup plans, restore simulation, failover execution, and post-recovery verification with policy-aware governance.

Pros:

  • Consistent and safer recovery operations across domains.
  • Faster incident response through one control surface.
  • Better auditability and compliance evidence for restore decisions.

Cons:

  • Requires sustained governance across web, BFF, and platform operations.

Decision Outcome#

Chosen option: Option 3.

Studio backup/disaster-recovery UX requirements:

  1. Backup plan governance contract for scope, cadence, retention, and owner metadata.
  2. Restore simulation contract for dry-run validation and impact analysis.
  3. Failover and restore execution contract with explicit policy/approval controls.
  4. Recovery verification contract for integrity checks and closure evidence.
  5. Telemetry/audit continuity contract for disaster lifecycle operations.

Normative Rules#

Backup Plan Integrity Rule#

  • Backup plans must include source scope, schedule, retention window, and owner attribution.
  • Plan changes must be versioned and reason-coded.
  • Missing required metadata must fail plan publish closed.

Restore Simulation Rule#

  • Restore actions must support dry-run simulation before production execution.
  • Simulation output must include affected entities, estimated duration, and integrity risk indicators.
  • Simulation failures must block promote-to-execute transitions.

Failover and Execute Governance Rule#

  • Production restore/failover actions require role/tier/approval validation.
  • Restore execution must include deterministic checkpoint and rollback metadata.
  • Unauthorized execution attempts must emit deny-path audit evidence.

Recovery Verification Rule#

  • Recovery completion requires validation of cross-domain integrity checks.
  • Open discrepancies must block incident closure.
  • Verification outcomes must be attached to recovery evidence package.

Telemetry and Audit Continuity Rule#

  • Backup, simulation, failover, and verification steps must emit telemetry and audit records.
  • Missing telemetry/audit continuity must trigger degraded-observability mode.
  • Governance exports must include actor, policy, action, outcome, and trace lineage.

Architecture Implications#

  • Studio web introduces dedicated backup/disaster-recovery workspace flows.
  • BFF exposes backup plans, simulation, restore, and verification APIs with policy enforcement.
  • Platform services provide snapshot inventory, failover orchestration, and checkpoint evidence.
  • Operational dashboards and runbooks require recovery SLOs and escalation mappings.

Acceptance Criteria (OST-00305)#

OST-00305 is complete only when:

  1. ADR exists at docs/adr/ADR-0057-oshun-studio-backup-and-disaster-recovery-ux.md.
  2. ADR defines options, trade-offs, and selected strategy.
  3. ADR defines backup plan, restore simulation, failover/execute governance, recovery verification, and telemetry/audit rules.
  4. ADR aligns with ADR-0007 through ADR-0050, especially ADR-0012, ADR-0039, ADR-0041, and ADR-0050.
  5. ADR aligns with existing resilience, observability, and operational governance surfaces.
  6. ADR explicitly covers Yemaya, Isis, Hathor, Aja, Bellona, and Project Obsidian.

Consequences#

Positive#

  • Stronger and faster disaster-recovery operations across Studio domains.
  • Better recovery safety via simulation-first and policy-gated execution.
  • Improved compliance/audit posture for backup and restore governance.

Negative#

  • Increased governance and operational complexity for recovery workflows.
  • Requires coordinated ownership between web, BFF, platform, and data teams.
  • docs/adr/ADR-0013-oshun-shell-architecture-and-domain-adapters.md
  • docs/adr/ADR-0018-analytics-taxonomy-and-event-naming.md
  • docs/adr/ADR-0045-oshun-studio-resilience-and-error-ux.md
  • docs/adr/ADR-0047-oshun-studio-observability-and-operational-dashboards.md
  • docs/adr/ADR-0056-oshun-studio-data-retention-and-lifecycle-controls.md

References#

  • docs/releases/v1/runbooks/studio-resilience-and-error-ux-runbook.md
  • docs/releases/v1/runbooks/studio-observability-and-operational-dashboards-runbook.md
  • docs/releases/v1/runbooks/studio-multi-project-operations-runbook.md
  • docs/releases/v1/runbooks/on-call-runbook.md