Parent folderOpen Confluence

RWS Architecture article

Backup and Disaster Recovery

Backup and Disaster Recovery is the product-neutral architecture building block for backup, restore, and disaster recovery orchestration for infrastructure and platform services. I

  1. Typeabb
  2. Statuscandidate
  3. Domainstorage
On this page
  1. ABB Backup and Disaster Recovery
  2. Summary
  3. Capabilities
  4. Constraints
  5. Service Description
  6. Roadmaps
  7. Landing Zones
  8. Interfaces
  9. Dependencies
  10. EIRA Alignment
  11. Available SBB's

ABB Backup and Disaster Recovery

Summary

Backup and Disaster Recovery is the product-neutral architecture building block for backup, restore, and disaster recovery orchestration for infrastructure and platform services. It states what DC 3.0 needs from this capability before a concrete SBB, product, or operating model is selected.

Capabilities

  • Provides backup, restore, and disaster recovery orchestration for infrastructure and platform services.
  • Defines the functional, technical, security, and quality expectations that SBBs must satisfy.
  • Keeps service ownership, interfaces, and consumption boundaries visible before product selection.
  • Enables traceability from architecture intent to implementation, operational evidence, and consuming services.

Constraints

  • The resulting SBB must fit the datacenters ownership model and document the support, lifecycle, and service-management boundary.
  • Security, privacy, logging, evidence, and compliance controls must be explicit enough to assess BIO2-aligned implementation where applicable.
  • Recovery objectives must be explicit per service tier before an SBB is accepted.
  • Restore procedures must be tested and evidenced, not only backed by backup-job success.

Service Description

This ABB offers a recoverability service that protects DC 3.0 services and provides tested restore paths for applications, platform state, and selected data services. It is consumed by solution architects, platform teams, and service owners as the capability contract for selecting and shaping SBBs.

The service description remains implementation-neutral: product selection, hosting pattern, detailed runbooks, and service levels belong in the mapped SBB and related ADRs.

Roadmaps

  • Baseline: confirm scope, service ownership, constraints, and acceptance criteria for Backup and Disaster Recovery.
  • MVP: validate the mapped SBB implementations and record the selected support and lifecycle model.
  • Next: add measurable service levels, evidence requirements, and roadmap dependencies once the SBB is selected.

Landing Zones

  • Private cloud and central DC 3.0 landing zone for core infrastructure and platform services.
  • Government cloud or external cloud landing zones only when the SBB documents the required control set, connectivity model, and data classification fit.

Interfaces

  • Backup APIs and storage targets.
  • Kubernetes backup and restore APIs where platform workloads are protected.
  • Monitoring, alerting, and evidence export interfaces.

Dependencies

  • Depends on block-file-s3-storage for a supporting capability or integration boundary.
  • Depends on automation for a supporting capability or integration boundary.
  • Depends on secrets-management for a supporting capability or integration boundary.
  • Implemented by cohesity, openshift-api-for-data-protection as currently mapped SBB traceabilities.
  • Consuming ABB and SBB dependencies must be recorded as links when solution design identifies concrete upstream or downstream use.

EIRA Alignment

Available SBB's

  • cohesity - Cohesity is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.
  • openshift-api-for-data-protection - OpenShift API for Data Protection is a candidate solution building block for the translated DC 3.0 ABB model. It remains candidate until the responsible architects confirm service ownership, support model, and acceptance criteria.