| Tier (proposed) | Availability | Pattern | RPO / RTO |
|---|---|---|---|
| Standard | 99.7% | Multi-zone, HA database, air-gapped backups | Zone: RPO ≈ 0. Region: restore from the vault. |
| Live DR | 99.9% | A second region running live | RPO seconds, RTO ≤ 15 min |
| Live DR Premium | 99.95% | Traffic in both regions, 24×7 priority | RPO seconds, RTO ≤ 5 min |
Non-production is 95%. Availability is measured monthly at the TRANXACT ingress, excluding the agreed maintenance window (proposed 4 hours a month).
Fix the tier before sizing. Live DR is a full-size second region and roughly doubles runtime infrastructure cost; show it as its own line, against the downtime cost it removes.
Live, not passive
A passive standby sits idle, is proven once a year if ever, and fails over by restoring and scaling up. Live DR runs a full-size cluster and a continuously replicated database that serve reads, reporting, ASK and synthetic postings all day. Failover is promotion — nothing is rebuilt — and its health is proven every minute.
| Test | Impact | How often | Category |
|---|---|---|---|
| Continuous verification — synthetic postings, lag alerts, cross-region ledger checksum | None | Every minute | Standard (TO_4.10.01) |
| Planned switchover drill — pause writes, promote, shift, verify; roles swap | Writes paused for seconds | Quarterly | Standard (TO_4.10.03) |
| Additional switchover drill | Writes paused for seconds | On request, 2 weeks ahead | Additional (TO_4.10.04) |
| Isolated drill — a fenced clone with integrations disabled | None on production | On request, 2 weeks ahead | Additional (TO_4.10.05) |
| Clean-room restore test | None on production | Yearly | Standard (TO_4.9.07) |
| Business validation after a drill | Customer effort | Each drill | Excluded (TO_4.10.06) |
Backups
| Production DB | Non-prod DB | |
|---|---|---|
| Taken | Daily snapshot + continuous logs | Daily snapshot |
| Recover to | Any point in 30 days | The last snapshot, 14 days |
| Vault copy | Daily, immutable, 90 days | Weekly, immutable, 30 days |
Documents are versioned continuously and copied daily to the vault for production. Infrastructure-as-code and configuration are in the vault too, so the runtime is rebuilt from code rather than restored.
Why the vault
Replication protects against outages, not corruption. Ransomware or bad data replicates to the standby and to the DR region within seconds. The vault is a separate account with separate identities and keys, no network path from production, write-once retention that even administrators cannot shorten, and dual-approval deletion. Restores from it go into an isolated environment — scan, reconcile, then promote — never straight over production.
A retention lock cannot be shortened once set. Extend it up front if audit or legal hold needs it, and size long-term copies from ledger growth and document volume, not today’s database size.
Calderwood chose Live DR at 99.9% in a second Azure region in the same jurisdiction. Its first switchover drill and a clean-room restore are scheduled before go-live as readiness gates. Its bank and payroll partners are written into the switchover plan so their endpoints follow the traffic manager.
Try it A batch job corrupts 4,000 Calderwood invoices at 14:05. Live DR is healthy, with 2 seconds of lag. Is failing over to the DR region the fix?
No. The corruption replicated to the standby and to the DR region seconds after it happened — failing over moves you to the same bad data. The answer is a point-in-time restore to 14:04 (TO_4.9.05, Standard) or, if the history itself is suspect, a clean-room restore from the vault (TO_4.9.06), with the finance controller signing off the restored data (TO_4.9.11).