Skip to content

PATTERN Cited by 1 source

Two-phase DR (read-only then read-write)

Intent

Separate disaster recovery into two phases with different RTOs, so critical read access is restored immediately while full read-write capability follows through a more deliberate orchestration — matching the reality that most DR consumers need to read data urgently but can tolerate a longer window before writing.

Mechanism

Phase 1: Immediate read-only access (minutes)

  • Pre-provisioned read-only volume clone serves stale-but-consistent data
  • Application traffic redirected to read-only instance
  • Ongoing replication continues undisturbed
  • Users can access and query critical data

Phase 2: Full read-write recovery (longer)

  1. Stop writes on primary (freeze source)
  2. Apply final replication update to DR (minimize data loss)
  3. Break the replication relationship (make DR volume writable)
  4. Reverse replication direction (DR → primary for eventual failback)
  5. Fail over application compute to DR nodes
  6. Resume full read-write operations in DR region

Key insight

The pattern exploits the observation that in many workloads (especially financial data, analytics, reporting), read access delivers the majority of business value during a disaster. By decoupling read recovery from write recovery, the architecture can deliver business continuity (Phase 1) with minimal complexity while preserving data integrity guarantees for the full recovery (Phase 2).

Production reference

S&P Global's Capital IQ platform: Phase 1 via FlexClone (< 15 minutes) provides read-only access to global financial data; Phase 2 via SnapMirror break + reverse delivers full read-write when needed. The two-phase separation means clients experience minimal disruption — they can continue accessing essential financial information — while the full recovery process is underway.

(Source: sources/2026-07-07-aws-sp-globals-disaster-recovery-fsx-netapp-ontap)

Applicability

Best suited for: - Read-heavy workloads where query access is the primary business need - Financial data platforms with regulatory requirements for data availability - Analytics / reporting systems where consumers primarily read - Production code releases where read-only DR doubles as a release-safe fallback

Less suitable for: - Write-heavy transactional systems where reads without writes are meaningless - Systems with strict read-write consistency requirements during degraded operation

Last updated · 569 distilled / 1,714 read