13.4 Autonomous Data Guard & Backup-Based Disaster Recovery for Autonomous AI Database

Choosing a Disaster Recovery Option

Autonomous AI Database Serverless gives you a menu of disaster recovery (DR) options, each with its own RTO, RPO, and cost. Oracle describes the choices this way:

• By default, every database has a local Backup-Based Disaster Recovery peer.
• To add automatic failover and lower the RTO, add a local Autonomous Data Guard standby.
• For the most resilient setup, add a local Autonomous Data Guard standby and one or more cross-region Autonomous Data Guard standbys.
• For a lower-cost regional option with a higher RTO, add a cross-region Backup-Based Disaster Recovery peer.

Local Autonomous Data Guard Standby

When you enable a local standby, Autonomous AI Database provisions an identical standby in the same region:

• In regions with more than one availability domain, the standby is in a different AD.
• In single-AD regions, it is in a different fault domain (a different physical machine).

You cannot connect to a local standby. You perform operations such as scaling ECPUs or enabling auto scaling on the primary, and Autonomous Data Guard mirrors them on the standby. After a local failover or switchover, client applications keep the same connection strings and wallets, the private endpoint and ACLs carry over, and APIs and scripts keep working. Oracle recommends a regional subnet for private endpoints for the best availability.

Zero data loss protection. Redo is sent synchronously to the local standby, and the primary does not commit until the standby acknowledges receipt. If acknowledgments are delayed (for example by a network problem), the standby can temporarily fall back to asynchronous transport to protect primary availability. This protection is included at no extra cost.

Automatic failover and the data loss limit. Automatic failover is configured by default to require zero data loss. You can set a data loss limit between 0 and 3,600 seconds. If Autonomous Data Guard determines that the potential data loss would exceed the limit, it does not fail over automatically, and you can choose a manual failover. After a local failover completes, a new local standby is created automatically.

Cost. A local standby adds the cost of the primary's base CPUs and storage, billed on the primary.

Cross-Region and Cross-Tenancy Standbys

A cross-region standby protects against the loss of a whole region. With the ECPU model you can add multiple cross-region peers, one per paired region. A standby can also live in a different tenancy, in the same or another region, which adds isolation (for example against ransomware) and can be used to migrate a database between tenancies.

Key differences from a local standby:

• No automatic failover. If the primary and the local standby are unavailable, you manually fail over to the cross-region standby.
• You cannot connect to a cross-region standby while it is a standby, and it is not available for read-only queries.
• Connection strings and wallets contain only the hostname of their own database. After a cross-region switchover or failover, applications must use the wallet or connection string from the new primary, or connection strings that you build manually with both hostnames. Oracle recommends failing over the mid-tier with the database to avoid cross-region latency, which is a job for Full Stack DR.
• Private endpoints, network ACLs, and tags can be configured independently on the remote peer. For private endpoints in different VCNs, cross-region wallets need remote VCN peering and DNS forwarding.
• Tool URLs (Database Actions, APEX, ORDS) change after a cross-region role change.
• Customer-managed keys require the Vault key to be replicated to the standby region; because a vault replicates to only one region, CMK supports only a single cross-region standby.
• Cost: base CPUs plus twice the primary's storage, billed on the remote peer.

Backups With a Cross-Region Standby

Automatic backups are taken only on the database in the primary role. By default they are not replicated. When you enable cross-region backup replication, up to 7 days of automatic backups are copied to the standby region so you can restore or clone there after a role change.

Backup-Based Disaster Recovery

Backup-Based Disaster Recovery uses backups instead of a running standby. The local peer costs nothing beyond automatic backup storage. A cross-region peer is billed for twice the replicated backup storage. Choose it when an RTO of hours is acceptable and a standby's CPU cost is not justified.

Snapshot Standby for DR Testing

A cross-region peer, whether an Autonomous Data Guard standby or a Backup-Based Disaster Recovery peer, can be converted to a snapshot standby. A local peer cannot. The snapshot standby is a read-write database for up to two days (48 hours):

• Redo from the primary is still sent to the region, keeping you protected, but it is not applied until the snapshot standby reconnects.
• On reconnect, manually or automatically at 48 hours, all changes made on the snapshot standby are discarded and the accumulated primary changes are applied.
• The primary has no downtime during conversion or reconnection, which makes snapshot standbys useful for testing the DR environment, including mid-tier configuration, without a switchover.

Autonomous Data Guard on Dedicated Exadata Infrastructure

On Dedicated Exadata Infrastructure, Autonomous Data Guard is enabled on the Autonomous Container Database (ACD), so it protects every database in the container:

• Protection mode: Maximum Performance (default, asynchronous) or Maximum Availability (synchronous).
• Automatic failover (fast-start failover) can be enabled. In Maximum Performance mode, the fast-start failover lag limit defaults to 30 seconds and can be set from 5 to 3,600 seconds, bounding data loss before an automatic failover.
• When a configuration has a local standby and a remote one, the local standby is preferred as the automatic failover target.
• Operations include switchover, failover, reinstating a disabled standby, and converting the standby ACD to a snapshot standby.