Oracle Exadata Multi-Cloud Disaster Recovery: AWS, Azure & Google Cloud Strategies

On this page

1. 01 · Why DR Needs a Fresh Look on Database@
2. 02 · RPO, RTO and Where the Standby Can Live
3. 03 · A Reference Topology for Cross-Cloud DR
4. 04 · Four DR Strategies Compared
5. 05 · What Changes on AWS, Azure and Google Cloud
6. 06 · The Failover Runbook
7. 07 · Testing DR Without Taking Risks
8. 08 · Sizing and Cost Choices
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Why DR Needs a Fresh Look on Database@

DR brief · Recovery strategies for Exadata inside AWS, Azure and Google Cloud

"Our database is on Exadata. Isn't that already highly available?"

It is, inside one site. Exadata gives you redundant database servers, mirrored storage across storage servers and RAC to survive a node failure without downtime. What it cannot do on its own is survive the loss of the data center, a regional network failure, or a logical error that is faithfully replicated to every mirror. Disaster recovery is about those events, and they need a second copy of the database somewhere else.

The Database@ model adds new choices for where that second copy lives. The standby can sit in another region of the same hyperscaler, in an OCI region over a private interconnect, or, as a design pattern, in a different hyperscaler altogether. Backups can land in the hyperscaler's object storage or in OCI. The right combination depends on how much data you can lose, how long you can be down and how much you are willing to pay to shrink both.

02 · RPO, RTO and Where the Standby Can Live

Answer: RPO is how much committed data you can afford to lose; RTO is how long the service can be unavailable. For Exadata on Oracle AI Database@AWS, @Azure or @Google Cloud, the standby can live in a second region of the same cloud, in an OCI region, or in another cloud, and each placement trades simplicity against independence.

Start with the business numbers, not the architecture. A reporting mart may tolerate a day of lost data and a day of downtime; a payments ledger may tolerate seconds of data loss and minutes of downtime. Those targets map directly to the Oracle Maximum Availability Architecture tiers: Bronze for backup-based recovery, Silver for local RAC, Gold for Data Guard to a second site, and Platinum for GoldenGate and near-zero downtime.

03 · A Reference Topology for Cross-Cloud DR

Answer: A practical cross-cloud DR topology has a primary Exadata cluster in one Database@ region, a Data Guard standby either in a second region of the same cloud or in OCI, backups in object storage, a fast-start failover observer in a third location, and health-checked DNS that moves users to the surviving site.

The figure below draws the primary on Oracle AI Database@AWS and two alternative standby placements: Option A in a second AWS region and Option B in an OCI region. The same pattern applies with Azure or Google Cloud as the primary. Global DNS sits above everything, sending users to the live application tier. The observer sits outside both sites so it can tell a real outage from a network partition.

The green arrow is today's user path; the grey dashed arrows are the paths DNS switches to after failover. The purple lines are redo transport, and Option B's line runs over a private interconnect rather than the internet. Note that each standby site needs its own application tier, warm or built on demand. Recovering the database without the application is not recovery.

Why the observer location matters

Fast-start failover (FSFO) lets the Data Guard broker fail over automatically when the observer and the standby both lose contact with the primary. If the observer runs in the primary's region, a regional outage takes it down too. Run it in a third region, in OCI, or on premises, and run a second observer for resilience.

04 · Four DR Strategies Compared

Answer: Backup and restore is cheapest but loses hours of data and takes hours to recover. A Data Guard standby cuts RPO to seconds and RTO to minutes. Active Data Guard adds read-only use of the standby. GoldenGate active-active gets close to zero on both, at the highest cost and complexity.

The comparison below rates the four strategies on four axes. Shorter bars are better in every column, so a strategy that is short everywhere does not exist: you are always trading money and effort for less data loss and less downtime.

The jump from the first row to the second is the biggest win per dollar in the chart. Moving from nightly backups to a Data Guard standby turns hours of potential data loss into seconds. The last row is only worth its cost when the application can genuinely run on two writable databases and handle conflicts.

05 · What Changes on AWS, Azure and Google Cloud

Answer: The database layer is identical: Data Guard, RMAN and GoldenGate behave the same in every Database@ partnership. What differs is the surrounding cloud: where backups land, how DNS failover is done, how the network between regions is built and which native tools see the event.

Plan these per cloud so that the database failover is not the fastest part of an otherwise slow recovery.

One detail catches many teams: the DR region must actually offer the Exadata service you need. Exascale and dedicated infrastructure roll out region by region, so check the standby region's service list as carefully as the primary's. If the DR region offers a different deployment type from the primary, for example ExaDB-D where the primary runs on Exascale, confirm with Oracle that a Data Guard pairing across the two is supported before you plan on it.

06 · The Failover Runbook

Answer: A failover runbook has seven steps: detect, scope, decide, fail over, redirect clients, validate and re-protect. RTO is measured from the first alert to users working again, so detection, decision and client redirection matter as much as the Data Guard command itself.

Most teams time the FAILOVER command and call that their RTO. In real incidents the command takes a small part of the total. The figure lays out the full runbook and marks where the RTO clock starts and stops.

The red bracket shows that the RTO window spans six of the seven steps. Automating the decision with fast-start failover shortens the third step; services, FAN and short DNS time-to-live values shorten the fifth. Re-protection happens after the RTO target, but until it is done you are running without DR.

-- One-time broker setup on the primary
DGMGRL> CREATE CONFIGURATION sales AS PRIMARY DATABASE IS sales_aws1
        CONNECT IDENTIFIER IS sales_aws1;
DGMGRL> ADD DATABASE sales_dr AS CONNECT IDENTIFIER IS sales_dr;
DGMGRL> ENABLE CONFIGURATION;
DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXPERFORMANCE;

-- Optional automatic failover with an observer in a third location
DGMGRL> EDIT DATABASE sales_dr SET PROPERTY FastStartFailoverTarget='sales_aws1';
DGMGRL> ENABLE FAST_START FAILOVER;
DGMGRL> START OBSERVER dr_obs1 IN BACKGROUND;

Use role-based database services so that the application always connects to whichever database currently holds the primary role. With services and Fast Application Notification in place, connection pools reconnect without a code change.

07 · Testing DR Without Taking Risks

Answer: Test DR on a schedule with three exercises: regular switchovers that swap roles with no data loss, snapshot standby tests that open the standby for writes and then revert, and periodic restore tests from object storage backups. Record the measured RPO and RTO each time.

A standby that has never been opened as a primary is a hope, not a plan. Oracle gives you safe ways to exercise it.

1. Switchover drill. Swap roles with the broker during a planned window, run the application from the DR site for a period, then switch back. No data is lost.
2. Snapshot standby test. Convert the standby to a snapshot standby, let testers write to it, then convert back. Redo keeps arriving and is applied afterwards.
3. Restore test. Restore a recent backup from object storage into a scratch cluster and open it. This proves the Bronze path still works.
4. Application and DNS test. Fail the full stack over, including DNS, secrets, batch schedulers and monitoring, not just the database.
5. Measure and record. Write down the achieved RPO and RTO and compare them with the targets. Fix the slowest step first.

The best DR design is the one your team has failed over and back at least twice, with the application, DNS and monitoring all following the database.

08 · Sizing and Cost Choices

Answer: Size the standby to run production after failover, or keep it smaller with a tested scale-up step. Use Active Data Guard so the standby carries read workloads, and consider Exascale for standbys where its lower minimum cost fits the service level.

A standby that sits idle is the most visible cost in any DR design. There are three ways to make it easier to justify.

• Put it to work. Active Data Guard lets reports, extracts and backups run on the standby, taking load off the primary.
• Right-size, then scale. Run the standby with fewer ECPUs and scale up as part of the failover runbook, but only if you have tested that the scale-up completes within your RTO.
• Use Exascale where it fits. Exascale (ExaDB-XS) bills by ECPU and storage with a much lower entry point than dedicated infrastructure, which suits standbys for small and medium databases.

09 · Key Takeaways

1. Set RPO and RTO first. The business targets map to an MAA tier, and the tier decides the strategy.
2. Data Guard is the default engine. A physical standby in another region or in OCI turns hours of exposure into seconds and minutes.
3. Place the observer and the app tier deliberately. A database without its application, DNS and observer is not recovered.
4. Check the DR region's services. Exascale and dedicated infrastructure roll out region by region; verify the standby region too.
5. Drill twice a year at least. Switchovers, snapshot standby tests and restores prove the design and measure the real RPO and RTO.

10 · Frequently Asked Questions