Disaster Recovery (DR)

It is the plan for restoring an application and its data after a serious outage. The recovery location might be another OCI region or, in a multi-cloud design, another cloud provider.

Its the plan and infrastructure that lets your systems survive and recover from a major failure (region outage, ransomware, hardware loss) with minimal downtime and data loss.

How to actually choose — 3-question rule:

How long can the business survive being down? → sets your RTO target

How much data can you afford to lose? → sets your RPO target

What's the budget vs criticality trade-off? → picks your point on the spectrum

• RTO — Recovery Time Objective: How long can the application be unavailable? If the target is one hour, the team aims to restore service within one hour.

• RPO — Recovery Point Objective: How much recent data can the business afford to lose? If the target is five minutes, the recovered data should ideally be no more than five minutes behind.

In OCI context: this maps directly to Data Guard (database DR), cross-region Object Storage replication, Traffic Management Steering Policies (DNS failover), and the Warm Standby / Pilot Light / Active-Active patterns we discussed earlier for hub-and-spoke architectures.

What is Requirement, benefits, consideration

Type of DISASTER RECOVERY

DR strategies fall into two groups: the cloud-native cost/speed spectrum (4 types), and deployment models describing where DR lives.

Cloud Native Specturm

1.Backup and Restore — just take regular backups, restore only if disaster hits. Cheapest, but recovery takes hours to days. Good for non-critical, low-budget workloads.

2. Pilot Light — core infrastructure (database, minimal config) kept running idle in the DR region; everything else spun up only during failover. RTO in tens of minutes.

3. Warm Standby — a scaled-down but fully functional copy of production runs continuously in the DR region; you scale it up when disaster strikes. RTO in minutes — this is the one we picked earlier for your OCI hub-and-spoke DR scenario.

4. Multi-site Active-Active — both regions fully live and serving traffic simultaneously; if one fails, the other absorbs load instantly. Near-zero RTO/RPO, but the most expensive and complex to run.

---

Deployment models

5. Cold Site DR — an empty pre-provisioned environment (network, storage shell) with zero running compute; everything must be built/restored from scratch during failover. Slower than Pilot Light, cheaper to maintain. Common in traditional enterprise DR contracts.

6. Hot Site DR — a fully mirrored, always-on duplicate environment ready to take over instantly — essentially the traditional (pre-cloud) term for what cloud calls Multi-site Active-Active.

7.Hybrid DR (On-prem ↔ Cloud) — primary system stays on-premises, DR site lives in the cloud (or vice versa). Very common for enterprises migrating gradually — matches exactly the on-prem-to-OCI DRG/FastConnect pattern we discussed earlier.

8. Cloud-to-Cloud DR (Multi-cloud DR) — primary on one cloud (e.g. OCI), DR site on a different cloud (e.g. AWS/Azure) — protects against a single cloud provider's regional or platform-wide outage, not just a data center failure.

9.Database-level DR — DR handled specifically at the database layer rather than whole-infrastructure level — e.g. OCI Data Guard, AWS RDS Cross-Region Read Replica, Always-On Availability Groups. Common when only the database is business-critical, not the full app stack.

10. Backup-as-a-Service (BaaS) / DRaaS — DR entirely outsourced to a third-party provider (e.g. Zerto, Veeam, Azure Site Recovery) who manages replication, failover, and testing as a managed service — popular for organizations without in-house DR expertise.

11. Chaos Engineering-driven DR — proactive approach where failures are deliberately injected (Netflix's Chaos Monkey model) to continuously validate DR readiness, rather than only testing during scheduled drills.