Patterns
| Pattern | DR region during normal running | Typical RTO | Typical RPO |
|---|---|---|---|
| Backup and restore | Backups copied cross-region; nothing running | Hours–days | Hours |
| Pilot light | Data replicated; compute not running (or minimal) | Hours | Minutes |
| Warm standby | Scaled-down stack running | Minutes–1 hour | Seconds–minutes |
| Active-active | Full capacity serving in both regions | Near zero | Near zero (data design dependent) |
Typical ranges, not promises; drills tell you what you actually achieve.
1. Tier the workloads
| Tier | Example | Pattern |
|---|---|---|
| Tier 0 | Identity, DNS, network, security tooling | Designed with the platform; must be up first |
| Tier 1 | Revenue / customer-facing | Warm standby or active-active |
| Tier 2 | Internal business apps | Pilot light |
| Tier 3 | Reporting, dev/test | Backup and restore |
2. Map layers to OCI services
| Layer | Backup-restore | Pilot light | Warm standby |
|---|---|---|---|
| Compute | Boot volume backups copied cross-region; custom images | Block/boot volume cross-region replication; instances created at failover | Running smaller instance pools |
| Oracle databases | Backups to cross-region Object Storage | Data Guard standby (can be small) | Data Guard / Autonomous Data Guard cross-region |
| Other databases | Dumps/backups copied | Native replication | Native replication, warm replicas |
| Object Storage | Replication policy | Replication policy | Replication + app config for region |
| OKE | Rebuild from IaC + GitOps; volume backups | Pre-created cluster, scaled down | Running cluster, minimal replicas |
| Traffic | Manual DNS change | DNS steering failover | DNS steering failover (health-checked) |
3. Don't forget Tier 0
- Identity: identity domains are regional with replication options (check your domain type); federation (IdP) reachable from DR; break-glass users tested.
- Network: DR region VCNs, DRG, FastConnect/VPN to DR, firewall policies, private DNS views.
- Keys: Vault keys available in the DR region for replicated encrypted data.
- Limits and capacity: service limits and shapes available in the DR region (GPU and large shapes especially).
- Secrets and certificates present in the DR region.
4. Orchestrate with Full Stack DR
Full Stack DR builds DR plans from protection groups (compute, volume groups, databases, load balancers, OKE where supported) and runs them in order, with custom scripts for app steps. It turns a 40-page runbook into a repeatable plan you can drill (see the Full Stack DR post).
5. Decide who declares a disaster
Automatic database failover (fast-start failover) vs a human decision for the whole application. Write down who decides, using which signals, after how long, and the communication path.
6. Drill
At least yearly per Tier 1/2 workload: switchover (planned) and, where feasible, a failover test in an isolated way. Record achieved RTO/RPO, and fix the gaps found.
Design review questions
- What's the RTO/RPO, and who signed it off?
- What still points at the primary region (hostnames, IPs, config, third-party allow-lists)?
- What's the order of recovery across dependent applications?
- How do you fail back, and how long does it take?
Tip
Fault domains and availability domains handle far more real incidents than region failover. Make Tier 1 workloads resilient within the region first, then add cross-region DR.
Checklist
- Workloads tiered with agreed RTO/RPO
- Pattern chosen per tier and mapped per layer
- Identity, network, keys, limits, secrets covered in DR region
- Full Stack DR plans built
- Disaster declaration process documented
- Drills run; failback planned