DR Across Clouds With Database@Azure and Full Stack DR

Disaster recovery is where multicloud architectures show their seams. On a single cloud, one control plane orchestrates the database, the application servers, and the DNS records. Database@Azure breaks that symmetry on purpose. The database layer is Oracle Exadata, provisioned and operated through the OCI control plane, physically installed inside Azure datacenters. The application layer is ordinary Azure: virtual machines, AKS clusters, App Service, Front Door, Azure DNS. When a region degrades, half of your recovery actions run through Oracle tooling and half through Microsoft tooling, and the two halves have no native awareness of each other.

This article is part of our multicloud database series. The pillar, our buyer guide to Oracle Database@Azure, @AWS, and @Google Cloud, covers the strategic choice across providers; here we focus on a single discipline for a single platform. If you are still forming a picture of the service itself, start with our complete guide to Database@Azure and come back. What follows assumes the platform decision is made and the question is how this estate survives a bad day.

Why DR for Database@Azure is genuinely different

Most DR literature assumes one of two shapes: everything in one cloud, or a primary datacenter with a recovery site you own. Database@Azure fits neither. The Exadata infrastructure sits in an Azure region, but it is provisioned, patched, and recovered through OCI constructs. Data Guard is configured through Oracle tooling. Backups land in object storage governed by Oracle policies. Meanwhile the connections your applications use traverse Azure virtual networks, delegated subnets, and private endpoints, a layer with its own failure modes that we cover in our article on Database@Azure networking.

The practical consequence is that no single pane of glass can fail the whole stack over. Azure Site Recovery does not know your standby database exists. OCI Full Stack DR cannot reach into Azure to repoint Front Door. A DR plan for this estate is a choreography problem before it is a technology problem: two orchestrators, each authoritative for its half, sequenced by your runbook.

There is a second difference planners often miss. The set of Azure regions that host Database@Azure is smaller than the set of Azure regions overall, and it changes as the footprint expands. Your preferred DR pair may not both offer the service, which constrains topology before any architecture discussion begins. Check the current availability map early, and see our breakdown of regions and availability for the Database@ services for how to reason about footprint risk.

The building blocks

The underlying machinery is the most battle proven DR technology in the database world. Nothing about Database@Azure weakens Data Guard; the design work is deciding where each replica lives and which control plane drives it.

Data Guard between Database@Azure regions. Where two Azure regions both host the service, you run a standby Exadata VM cluster in the second region with Data Guard replication between them. Applications in the secondary region connect locally after failover, and the pattern feels familiar to any Oracle DBA. This is the default for production when the footprint allows it.

Data Guard to a native OCI region. The standby does not have to live inside Azure at all. A standby in a native OCI region gives you a recovery site on entirely independent infrastructure, outside both the Azure region pair and the Database@Azure dependency chain. The trade off is that after failover your Azure application tier reaches the database over an interconnect or VPN path, with the latency and egress implications that brings.

Autonomous Data Guard. For Autonomous Database on Database@Azure, the platform manages the standby for you, with options for local and cross region protection. You give up granular control of the topology in exchange for automation that is very hard to misconfigure. For many workloads that is exactly the right trade.

Backups. Underneath every replication strategy sits the backup tier: automatic backups to OCI object storage by default, with options to direct copies toward Azure storage where residency or tooling demands it. Backups are no substitute for a standby when recovery time is measured in minutes, but they are the only protection against logical corruption, which replication will happily copy to your standby.

What OCI Full Stack DR does, and where it stops

OCI Full Stack DR is Oracle's orchestration service for exactly this class of problem within OCI: you define DR protection groups containing databases, compute, load balancers, and volumes, and the service generates and executes ordered DR plans for switchover, failover, and drills. It handles the sequencing that runbooks usually get wrong, validates plans against the live environment, and produces an execution log that auditors can actually use. For the OCI resident portion of a Database@Azure estate, it turns a wiki page of manual steps into push button automation, with drill operations so you can rehearse without touching production.

Its limit is the obvious one: it orchestrates OCI resources. When half your stack is native Azure, Full Stack DR will fail your database over cleanly and then stop at the cloud boundary. It will not rebuild your AKS ingress, repoint Traffic Manager, or update Azure DNS. The honest architecture builds a thin coordination layer above both clouds: a runbook, ideally automated, that invokes Full Stack DR plans for the Oracle half and Azure native automation for the Microsoft half, with explicit checkpoints between the two. Treat that layer as production software, version controlled and tested, not as a document.

Choosing a topology

Topology locks in most of your cost and most of your protection, so decide it per workload rather than once for the estate. Four patterns cover nearly every case.

Two notes on reading this table honestly. First, the second row protects against a regional disaster but both sites still share the Database@Azure operating model; if your regulator asks what happens if the partnership itself has a bad day, only the third and fourth rows answer that. Second, the fourth row looks cheap and rarely is. An on premises standby that nobody patches and nobody tests is a compliance artifact, not a recovery site.

Most real estates mix patterns: zone level protection plus a cross region standby for tier one systems, backup based recovery for development and test, and perhaps one regulated workload with a native OCI standby for independence. The mistake is paying for the top row of protection on workloads whose owners would tolerate a four hour recovery.

Aligning the application tier

The database is usually the best protected component in the stack, which creates a seductive failure mode: the database fails over flawlessly and the application tier does not follow. Sessions die, connection strings point at a primary that is now a standby, and the business experiences a full outage even though the data layer performed perfectly.

On the Azure side, the toolkit is conventional and good. Azure Site Recovery replicates virtual machines across regions. AKS and App Service workloads redeploy from pipelines or run active in both regions behind Traffic Manager or Front Door. DNS cutover, health probes, and connection string management round out the picture. None of this is exotic; what is exotic is the sequencing. Your runbook must define whether the app tier moves first, the database moves first, or both move in parallel with a verification gate. Connection services with role based routing mean application connections follow the primary automatically after a Data Guard role change, but only if someone configured them, and only if the app tier can reach the new primary over network paths you prepared in advance.

Day to day discipline determines whether any of this works when called upon. Observer placement, lag monitoring, patch alignment between primary and standby, and drift detection between the two clouds are weekly disciplines, not annual ones. Our article on operating Database@Azure covers the broader run model that DR readiness sits inside.

A 7 step DR design framework

This is the sequence we use when we design or audit DR for a Database@Azure estate. The order matters.

Where the costs hide

DR budgets fail in predictable places. The standby infrastructure is the visible cost, and on Exadata it is substantial: a cross region standby means a second dedicated footprint billed whether or not it ever takes a transaction. Running standbys smaller than primaries, or putting them to work for read only reporting and backup offload, recovers some of that spend, but the floor is real.

The quieter costs are in the network. Steady state replication pushes redo across regions or clouds every hour of every day, and on cross cloud topologies that traffic can meter as egress. Failback is the cost nobody models: after weeks in the secondary, you reinstate and resynchronize in the other direction, and a full reinstate can dwarf months of steady state replication. Then there is idle capacity: DR environments accrete test VMs, forgotten clones, and oversized standbys that nobody reviews because the environment is not production. An annual right sizing pass routinely finds savings, and it is one of the places our optimization work, where the fee is paid only on verified savings, earns out fastest.

Common DR mistakes we keep finding

• Testing failover but never failback. Half the disaster is getting home, and the reinstate path is where untested plans break.
• Observers in the wrong failure domain. An observer colocated with the primary vanishes exactly when it is needed.
• Connection strings pinned to one site. Applications hard wired to a hostname instead of role based services that follow a role change.
• Plans that assume the people are available. The one engineer who knows the runbook is on a plane during the outage.
• Protecting the database and forgetting its dependencies. Wallets, key management, and integration endpoints that exist only in the primary region.
• Letting drift accumulate between sites. Patch levels, parameters, and network rules that diverge until the standby cannot carry production.
• Declaring DR done after the project closes. Readiness decays from the last successful test, and quarterly drills are the only countermeasure.

Where independent specialists fit

Neither Oracle nor Microsoft will design this end to end, because each is authoritative for only half the stack, and neither has an incentive to point out that your topology is overbuilt by a tier or that your standby has never carried a real workload. This is structurally a job for someone whose accountability spans both control planes and whose incentives point at your recovery objectives rather than at consumption.

In practice the engagement takes one of three shapes. DR design and the first tested switchover is bounded work, well suited to a fixed project fee: classify, choose topologies, build the Full Stack DR plans and the Azure side automation, and hand over a runbook that has actually executed. Ongoing readiness, the quarterly drills, lag monitoring, drift detection, and runbook maintenance, fits a Managed Monthly retainer backed by 24/7/365 monitoring. And periodic right sizing of standby capacity fits an optimization engagement where the fee is a share of verified savings, so the review costs nothing unless it finds something. Our disaster recovery solution page covers how we structure all three.

Bringing it together

DR for Database@Azure is not harder than DR anywhere else; it is differently shaped. The database machinery is as proven as enterprise software gets, and Full Stack DR gives the OCI half real orchestration. The difficulty lives at the seam: two control planes, a topology decision with real money attached, and an app tier that must move in step with a database it cannot see. Classify honestly, choose topology per tier, engineer the runbook as software, and rehearse quarterly until a switchover is a non event. The estates that recover well are never the ones with the most expensive architecture. They are the ones where the plan had been executed so many times that the disaster was just another drill with worse coffee.