Use Backup-Based Disaster Recovery

Backup-Based Disaster Recovery provides a lower-cost disaster recovery option for Autonomous Database (the RTO is higher with this option, as compared to using Autonomous Data Guard).

Autonomous Database Disaster Recovery Options

  • Backup-Based Disaster Recovery: uses backups to instantiate a peer database at the time of switchover or failover. This enables you to have a lower cost and higher Recovery Time Objective (RTO) disaster recovery option for your Autonomous Database, as compared with Autonomous Data Guard. For local Backup-Based Disaster Recovery, existing local backups are utilized. There are no additional costs for a local Backup-Based Disaster Recovery. Cross-Region Backup-Based Disaster Recovery incurs an additional cost.

    Backup-Based Disaster Recovery is available for all workload types.

  • Autonomous Data Guard: When you add an Autonomous Data Guard standby database, the system creates a standby database that continuously gets updated with the changes from the primary database. You can use Autonomous Data Guard with a standby in the current region, a local standby, or with a standby in a different region, a cross-region standby. You can also use Autonomous Data Guard with both a local standby and a cross-region standby.

    You can also create an Autonomous Data Guard standby in a different tenancy.

    Autonomous Data Guard is available for the following workload types:

    • Data Warehouse
    • Transaction Processing

    See Use Standby Databases with Autonomous Data Guard for Disaster Recovery for details on Autonomous Data Guard.

Topics

About Backup-Based Disaster Recovery

Backup-Based Disaster Recovery uses backups to instantiate a peer database at the time of switchover or failover. This enables you to have a lower cost and higher Recovery Time Objective (RTO) disaster recovery option for your Autonomous Database, as compared with Autonomous Data Guard.

You can use Backup-Based Disaster Recovery with a peer in the current region, a local peer, or with one or more disaster recovery peers in different regions, or you can add both a local disaster recovery peer and one or more a remote disaster recovery peers. You can also create a Backup-Based Disaster Recovery peer, either local or remote in a different tenancy.

Note

Backup-Based Disaster Recovery (backup copy) is available in all Autonomous Database workload types. Backup-Based Disaster Recovery is not available with Always Free Autonomous Database.

Backup-Based Disaster Recovery with Local Peer

For local Backup-Based Disaster Recovery, existing local backups are utilized. There are no additional costs for local Backup-Based Disaster Recovery.

Description of backup-based-dr-local.eps follows
For better resilience for Backup-Based Disaster Recovery, a peer is instantiated as follows:
  • In regions with more than one availability domain, a local peer is instantiated in a different availability domain than the primary database.
  • In regions with a single availability domain, a local peer is instantiated in a different fault domain than the primary database (that is, on a different physical machine).

All Autonomous Database features from the primary database are available when a peer is instantiated and becomes the primary, after the system fails over or after you perform a switchover operation. See Autonomous Data Guard with Local Standby for more information.

Backup-Based Disaster Recovery with Cross-Region Peer

For backup-based disaster recovery with a cross-region peer, backups are copied to the remote region. Cross-region Backup-Based Disaster Recovery incurs additional costs.

Description of backup-based-dr-cross-region.eps follows

Autonomous Database allows you to create one or more remote disaster recovery peer databases, depending on your compute model:

  • OCPU Compute Model: You can add one remote disaster recovery peer in a paired region. Paired regions are remote regions where you can create a cross-region peer.

  • ECPU Compute Model: You can add multiple remote disaster recovery peers, with up to one peer in each remote paired region. For example if your primary database is in the IAD region, you can add a remote peer in PHX and in SJC, but you cannot add two remote peers in PHX.

Paired regions are remote regions where you can create a cross-region disaster recovery peer. See Autonomous Database Cross-Region Paired Regions for more information on paired regions.

Topics

Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO)

When you perform a failover using with Backup-Based Disaster Recovery enabled, the peer instance assumes the role of the primary instance, according to the Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

The RTO is the maximum amount of time required to restore database connectivity to a backup copy database after a failover is initiated. The RPO is the maximum duration of potential data loss, in minutes, on the primary database.

Backup-Based Disaster Recovery RTO and RPO numbers are:

Backup-Based Disaster Recovery Configuration RTO RPO

Local backup copy

one (1) hour + 1 hour per 5 TB

10 seconds

Cross-region (remote) backup copy

one (1) hour + 1 hour per 5 TB

1 min

Replicating Backups to a Cross-Region Backup Based Disaster Recovery Peer

When you add a cross-region Backup-Based Disaster Recovery peer you can enable cross-region backup replication for automatic backups.

By default, automatic backups are created and maintained at the current Primary database and are not replicated to a cross-region peer. Optionally, you can enable replication of the automatic backups to a cross-region peer.

When you enable cross-region backup replication, up to 7 days of automatic backups for the primary are replicated to a cross-region peer. When this feature is enabled automatic backups are available in the remote region as follows:

  • After a switchover or failover you can restore or clone to any timestamp in the past seven (7) days, or to any timestamp in the specified retention period when the retention period is set to less than seven days.

  • All backups for the primary that are replicated to the remote region are deleted on the remote region peer after seven days, or after the retention period number of days when the retention period is set to less than seven days.

  • You cannot modify the backup retention period for replicated backups, except if you modify the backup retention period on the primary to specify a value less than seven days. In this case, the retention period for replicated backups on the remote region matches the automatic backup retention period set on the primary.

The cross-region backup replication incurs an additional cost. See Oracle Autonomous Database Serverless Features Billing for more information.

See the following for more information:

Note the following for cross-region backup replication:

  • After a switchover or a failover, while the cross-region database is in the primary role, backups are taken on the current primary and are replicated to the current (remote) peer.

  • When using Backup-Based Disaster Recovery with a cross-region peer, this feature is supported for all workload types.

View Backup-Based Disaster Recovery Peer

Backup-Based Disaster Recovery with a local peer is enabled by default for a newly created Autonomous Database instance, and for existing databases. A local Backup-Based Disaster Recovery peer does not incur any additional cost.

Perform the following prerequisite steps as necessary:

  • Open the Oracle Cloud Infrastructure Console by clicking the navigation icon next to Oracle Cloud.

  • From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.
  • On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

To view the disaster recovery information for your Autonomous Database, do the following:

On the Autonomous Database Details page, in the Resources area click Disaster recovery. The DR Type field indicates the type of disaster recovery, either Backup-Based Disaster Recovery (Backup copy) or Autonomous Data Guard.

For example:

Description of adb_backup_copy_resources.png follows

Add a Cross-Region Disaster Recovery Peer

In addition to a local Backup-Based Disaster Recovery peer, you can add one or more remote region (cross-region) Backup-Based Disaster Recovery peers.

Perform the following prerequisite steps as necessary:

  • Open the Oracle Cloud Infrastructure Console by clicking the navigation icon next to Oracle Cloud.

  • From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.
  • On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

To add a cross-region Backup-Based Disaster Recovery peer, do the following:

  1. On the Autonomous Database Details page, under Disaster recovery, in the Cross-region field, click Add peer database, alternatively in the Resources area click Disaster recovery.

    Description of adb_bbdr_ui_update.png follows

    Description of adb_backup_copy_resources.png follows
  2. Click Add peer database.
  3. In the Region drop-down list, select a region.

    The region list shows the available remote regions where you can create a cross-region peer. When you add a peer database, the list of available regions only shows a remote region if your tenancy is subscribed to the remote region (you must be subscribed to the paired remote region). See Autonomous Database Cross-Region Paired Regions for more information.

  4. In the Select a compartment drop-down list, select a compartment.
  5. Select the disaster recovery type. In addition, when the source database is configured with a private endpoint, enter the private endpoint information for the peer.
    1. Select the disaster recovery type: Backup-based disaster recovery.
    2. If you want to enable Cross-Region Backup Replication select the Enable cross-region backup replication to disaster recovery peer check-box. See Replicating Backups to a Cross-Region Backup Based Disaster Recovery Peer for more information.

      Description of adbs_bbdr_cross_region_replication.png follows

    3. When the source database is configured with a private endpoint, in the Network access for standby area enter the Virtual cloud network and the Subnet.
      Description of adb_create_cross_region_peer_private_endpoint.png follows

      In these Network access for standby fields you specify the private endpoint's VCN and Subnet on the remote region where the standby is created. Configure Private Endpoints.

      Note

      If you change your network access on the source database to enable a private endpoint after the standby is created, you must manually access the standby to enable a private endpoint on the peer.
  6. Click Add peer database.

    The Autonomous Database Lifecycle State changes to Updating. In the Resources area, the number next to Disaster recovery increments to show that you have another disaster recovery peer, and the State field shows Provisioning for the new cross-region peer.

    Note

    While you add a new peer, the primary database is available for read/write operations. There is no downtime on the primary database.

Notes for adding a cross-region Backup-Based Disaster Recovery peer:

  • Autonomous Database generates a work request. To view the work request, under Resources click Work Requests.

  • After you add a cross-region (remote) peer, the wallet, and connection string from the primary database will contain only the hostname of the primary database, and the wallet and connection string from the remote database will contain only the hostname of the remote database. This applies to both instance and regional wallets.

    See Cross-Region Disaster Recovery Connection Strings and Wallets for more information.

  • If you select Enable cross-region backup replication to disaster recovery peer, it can take between several minutes and several hours to replicate the backups to the remote region, depending on the size of the backups. After backups are replicated, when you select Backups under Resources on the peer database's Oracle Cloud Infrastructure Console, you will see the list of replicated backups.

  • When you add a cross region peer there are special considerations when the primary instance is using customer-managed keys, or if you want to switch to use customer-managed keys. See Autonomous Data Guard with Customer Managed Keys for more information.

  • While you add a Backup-Based Disaster Recovery peer, while the Lifecycle State field shows Updating, the following actions are disabled for the primary database:

Enable or Disable Backup Replication for an Existing Cross-Region Peer

You can enable or disable backup replication on a Backup-Based Disaster Recovery cross-region peer.

To enable or disable backup replication for an existing cross-region Autonomous Data Guard standby:

  1. On the Autonomous Database Details page, in the Resources area select Disaster recovery.
  2. In a row that lists a cross-region standby, click more actions at the end of the row and select Update disaster recovery.

    This shows the Update disaster recovery page.


    Description of adb_bbdr_update_backup_replication.png follows

  3. Enable or disable backup replication.
    1. If cross-region backup replication is disabled, select Enable cross-region backup replication to disaster recovery peer to enable the option.
    2. If cross-region backup replication is enabled, deselect Enable cross-region backup replication to disaster recovery peer to disable the option.
  4. Click Submit.

    The Autonomous Database Lifecycle State changes to Updating.

If you select Enable cross-region backup replication to disaster recovery peer, it can take between several minutes and several hours to replicate the backups to the remote region, depending on the size of the backups. After backups are replicated, when you select Backups under Resources on the peer database's Oracle Cloud Infrastructure Console, you will see the list of replicated backups.

Update Disaster Recovery Type

Describes the steps to change to an alternative Disaster Recovery option.

Backup-Based Disaster Recovery is enabled by default for an Autonomous Database with one local peer. Disaster Recovery cannot be disabled for an Autonomous Database instance. However, you can choose to update your Disaster recovery type to Autonomous Data Guard. See Use Standby Databases with Autonomous Data Guard for Disaster Recovery for more information about Autonomous Data Guard.

To update the Disaster recovery type:

  1. On the Primary Autonomous Database, on the Autonomous Database Details page under Resources, select Disaster recovery.
    Description of adb_backup_copy_resources.png follows
  2. In the row showing the database's disaster recovery details, click more actions at the end of the row and select Update disaster recovery type.
  3. On the Update disaster recovery type page, choose Autonomous Data Guard.
    Description of adb_update_dr_type_data_guard.png follows
  4. Click Submit. This starts provisioning an Autonomous Data Guard standby database.
  5. The disaster recovery type is changed to, Autonomous Data Guard, as shown in the DR Type column.

Disable a Cross-Region (Remote) Peer

Describes the steps to terminate a cross-region (remote) peer.

Perform the following prerequisite steps as necessary:

  • Open the Oracle Cloud Infrastructure Console by clicking the navigation icon next to Oracle Cloud.

  • From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.
  • On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

To terminate a cross-region (remote) peer:

  1. On the Primary database, on the Autonomous Database Details page under Resources, select Disaster recovery.
  2. Access the Oracle Cloud Infrastructure Console for the remote region peer.

    The Disaster recovery information area shows the Peer Autonomous Database. The remote peer has the same display name as the primary database, with an "_region" extension. Where region is the region name, such as IAD or BOM.

    If you created the cross-region peer before the introduction of support for multiple cross-region peers, the remote peer has the same display name as the primary database, with an "_Remote" extension.

    Under Peer Autonomous Database, click the link for the remote peer to access the cross-region peer.

  3. On the Oracle Cloud Infrastructure Console for the remote peer, on the Details page, from the More actions drop-down list, select Terminate.
  4. On the Terminate Autonomous Database page, enter the database name to confirm that you want to terminate the cross-region peer.
  5. Click Terminate Autonomous Database.

    While the peer is terminating, the Lifecycle State changes to Terminating.

There are limitations for disabling when an instance has a cross-region Backup-Based Disaster Recovery peer, as follows:

  • A peer in the remote region cannot be disabled from the primary database.

  • When Backup-Based Disaster Recovery is enabled with a cross-region peer, you must terminate all cross-region disaster recovery peers before you terminate the primary role database. If you attempt to terminate the primary, the system gives you an error.

    In this case, after you terminate all cross-region (remote) peers, you can terminate the primary database.

Perform a Switchover to a Backup Copy Peer

When you perform a switchover, the primary database becomes the backup copy and the backup copy becomes the primary database, with no data loss.

A switchover is typically done to test failover to the backup copy for audit or certification reasons, or to test your application's failover procedures when you have added a backup copy peer.

For switchover to a backup copy peer, the Autonomous Database Details page, shows the Switchover link under Disaster recovery and the Oracle Cloud Infrastructure Console on the primary database also shows a Switchover link in the Role field when both the primary database and a backup copy peer are available. You can perform a switchover when the primary database Lifecycle State shows Available or Stopped, and a backup copy is available (the State field shows Standby).

To see the peer state, under Resources click Disaster recovery and for the peer listed in the Peer Autonomous Database column, check that the State shows Standby.

Using the Autonomous Database API, you can initiate the switchover operation at any time. See Use the API for more information.

Perform a Switchover to a Local Backup Copy Peer

When you perform a switchover the primary database becomes the peer, and the peer becomes the primary database, with no data loss.

A switchover is typically done to test failover to the peer for audit or certification reasons or to test your application's failover procedures with Backup-Based Disaster Recovery.

For a switchover to a backup copy, the Autonomous Database Details page, the Oracle Cloud Infrastructure Console on the database with the Primary role shows a Switchover link in the Role field when both the primary database and a peer are available. You can perform a switchover when the primary database Lifecycle State shows Available or Stopped and a peer is available (the State field shows Standby).

To see the peer status, under Resources click Disaster recovery and for the peer listed in the Peer Autonomous Database column, check that the State field shows Standby.

Using the Autonomous Database API, you can initiate the switchover operation at any time. See Use the API for more information.

Perform the following prerequisite steps as necessary:

  • Open the Oracle Cloud Infrastructure Console by clicking the navigation icon next to Oracle Cloud.

  • From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.
  • On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

To perform a switchover, do the following:

  1. On the Autonomous Database Details page, under Disaster recovery, in the Role field, click Switchover.
    As an alternative, to initiate a switchover you can select More actions and Switchover or select Disaster recovery under Resources and Switchover.
  2. In the Confirm switchover to peer dialog, in the Select peer list, choose the peer to switchover.
  3. Enter the database name to confirm that you want to switch over.
  4. Click Confirm switchover to peer.

    When concurrent operations such as scaling are active, the confirmation also confirms either pausing or canceling the concurrent operation. See Concurrent Operations on Autonomous Database for more information.

    The database Lifecycle State changes to Updating. To see the state of the peer, under Resources, click Disaster recovery where the State column shows Role Change in Progress.

When the switchover completes, Backup-Based Disaster Recovery does the following:

  • The Backup-Based Disaster Recovery resource information is updated to reflect the switchover. Select Disaster recovery under Resources to see the updated information.

  • Autonomous Database reports the time in the Role Changed On the field.

Perform a Switchover to a Cross-Region Backup Copy Peer

When you perform a switchover, the primary database becomes the peer database and the peer database becomes the primary database, with no data loss.
Note

For a cross-region switchover you must initiate the switchover from the cross-region peer.

You have several options to access the cross-region peer:

  • Select the remote region in Oracle Cloud Infrastructure Console and then access the peer directly.

  • Access the primary, and from the primary database you can access the peer from the Autonomous Database Details page by selecting Disaster recovery, under Resources and clicking the link for the backup copy peer in the Peer Autonomous Database column.

To perform a switchover:

  1. On the cross-region peer, on the Autonomous Database Details page, under Disaster recovery, in the Role field, click Switchover.

    As an alternative, in the row showing the database's disaster recovery details, click more actions at the end of the row and select Switchover.

  2. In the Confirm switchover to peer dialog, enter the peer database name to confirm that you want to switch over.
  3. In the Confirm switchover to peer dialog, click Confirm switchover to peer.

    When concurrent operations such as scaling are active, the confirmation also confirms either pausing or canceling the concurrent operation. See Concurrent Operations on Autonomous Database for more information.

    The database Lifecycle State changes to Role change in progress. To see the state of the peer database, under Resources click Disaster recovery. The state State shows Updating.

When the switchover completes, Autonomous Database does the following:

  • The display name shows the Primary indicator.

  • The Disaster recovery resource information is updated to reflect the switchover. Under Resources select Disaster recovery to see the updated information.

  • Autonomous Database reports the time of the last switchover when you hover over the tooltip icon in the Role field.

See Notes for Performing a Switchover for more information.

Notes for Performing a Switchover to a Backup Copy Peer

Provides notes for Backup-Based Disaster Recovery switchover:

  • For a cross-region switchover, you must initiate the switchover from the cross-region peer.

  • During the switchover, most of the actions on the Oracle Cloud Infrastructure Console are not available and the Autonomous Database Information page shows the Lifecycle State with the value Updating.

  • The switchover operation keeps the original state of the Primary database. If the Primary database is stopped when you perform a switchover, the Primary database is stopped after the switchover.

  • Autonomous Database generates the Switchover Autonomous Database work request. To view the request, under Resources click Work Requests.

  • After a switchover or failover to the peer, the peer becomes the Primary and the graphs on the Database Dashboard card in Database Actions and the Oracle Cloud Infrastructure Metrics display information about the Primary database. The graphs and metrics do not contain information about the database that was the Primary before the switchover or failover operation.

  • You cannot cancel a cross-region switchover operation after the switchover begins and the State shows Role change in progress. Your options to cancel the switchover are:

    • Try or retry a switchover or a failover until the operation succeeds.

    • File a service request at Oracle Cloud Support or contact your support representative.

Perform a Failover

When the primary database goes down, with Backup-Based Disaster Recovery you can perform a manual failover to make the local peer the primary database.

Backup-Based Disaster Recovery does not provide an automatic failover option. If you want to provide automatic failover, where the system monitors the primary instance and automatically fails over to a local standby database in certain scenarios, you need to change the disaster recovery type for the local instance to use Autonomous Data Guard.

With both a local Backup-Based Disaster Recovery peer and a cross-region Backup-Based Disaster Recovery peer, Oracle recommends that you attempt a manual failover to the local peer first (not to the cross-region peer).

Depending on how you enable Backup-Based Disaster Recovery, there are different steps to perform a manual failover to a peer:

  • When you configure Backup-Based Disaster Recovery with only a local peer:

    When you have a local peer and the switchover is not successful, the Oracle Cloud Infrastructure console shows a banner with information about why the switchover was not successful and the Oracle Cloud Infrastructure console shows a failover link in the Role field that you can click to initiate a failover to the local peer. The failover link only shows when the Primary database is unavailable and a peer is available. That is, the Primary database Lifecycle State field shows Unavailable and the local peer is available. Using the API, you can initiate manual failover at any time. See Use the API for information on using the API.

    To see the peer status, under Resources click Disaster recovery and for the peer listed in the Peer Autonomous Database column check that the State field shows Available or Stopped.
  • When you use Backup-Based Disaster Recovery with both a local peer and a cross-region (remote) peer:

    With Backup-Based Disaster Recovery enabled with both a local peer and a cross-region peer, and the local peer is available, Oracle recommends that you attempt a manual failover to the local peer first (not to the cross-region peer).

    If a local peer is unavailable or a manual failover to the local peer fails, you can perform a manual switchover to the cross-region peer. If the switchover to the cross-region peer fails, on the peer the Oracle Cloud Infrastructure console shows a failover link in the Role field that you can click to initiate a manual failover to the peer.

When you initiate a manual failover it is failed over to the peer based on the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets. See Backup-Based Disaster Recovery Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for more information.

Perform the following prerequisite steps as necessary:

  • Open the Oracle Cloud Infrastructure Console by clicking the navigation icon next to Oracle Cloud.

  • From the Oracle Cloud Infrastructure left navigation menu click Oracle Database and then, depending on your workload click one of: Autonomous Data Warehouse, Autonomous JSON Database, or Autonomous Transaction Processing.
  • On the Autonomous Databases page select your Autonomous Database from the links under the Display name column.

To initiate a manual failover to a cross-region backup copy, do the following:

  1. On the peer, perform a switchover. See Perform a Switchover to a Local Backup Copy Peer for details.

  2. If the switchover attempt in Step 1 fails, on the peer the Role field shows a Failover link. On the peer, click the Failover link.

    This shows the Confirm manual failover to peer dialog, along with information on possible data loss that may result if you perform the manual failover to the peer.

  3. In the Confirm manual failover to peer dialog, enter the Autonomous Database name to confirm that you want to failover.

  4. In the Confirm manual failover to peer dialog, click Confirm manual failover to peer.

    When concurrent operations such as scaling are active, the confirmation also confirms either pausing or canceling the concurrent operation. See Concurrent Operations on Autonomous Database for more information.

To initiate a manual failover when the Primary database is unavailable and the local Peer is available, do the following:

  1. On the Details page, under Disaster recovery, in the Role field, click Failover.

    This shows the Confirm manual failover to peer dialog, along with information on possible data loss that may result if you perform the manual failover to peer.

    Description of adb_failover_manual.png follows
  2. In the Confirm manual failover to peer dialog, enter the Autonomous Database name to confirm that you want to failover.
  3. In the Confirm manual failover to peer dialog, click Confirm manual failover to peer.
When the failover completes, Backup-Based Disaster Recovery does the following:
  • After a manual failover operation completes you can see any data loss associated with the manual failover in the message on the Oracle Cloud Infrastructure console banner and if you hover over the tooltip icon in the Role field. The manual failover data loss is specified in minutes.

  • After a manual failover with Backup-Based Disaster Recovery, if there was a regional failure, when the region comes back online the peer is automatically reconnected or if required reprovisioned.

  • After you perform a manual failover to the cross-region peer, the cross-region peer becomes the primary database. In this case, if a local Autonomous Data Guard standby was enabled, a local Standby will be created and attached. If a local Autonomous Data Guard was not enabled before the failover in the primary database, as is the default, you have a local backup copy.

Convert Cross-Region Backup-Based Disaster Recovery Peer to Snapshot Standby

A cross-region Backup-Based Disaster Recovery peer can be converted to a snapshot standby. This converts the peer to a read-write database for up to two days.

Snapshot standby CPU usage is billed based on the base CPU count and any additional CPU usage if compute auto scaling is enabled. The number of base CPUs is specified by the number of ECPUs (OCPUs if your database uses OCPUs) as shown in the ECPU count or OCPU count field on the Oracle Cloud Infrastructure Console.

Snapshot standby storage usage is billed based on the storage of the snapshot standby plus 1 x the storage of the primary database.

Update Remote Peer Network ACLs for a Backup-Based Disaster Recovery Peer

You can independently modify network ACLs on a remote disaster recovery peer database.

By default the disaster recovery primary and remote peer databases use the same network Access Control Lists (ACLs). Optionally, you can configure ACLs independently on remote peer databases. This provides an option to use different ACLs on remote peer databases.

If you modify the ACLs on a remote peer, Autonomous Database no longer keeps the ACL configuration synchronized between the primary and the remote peer. After you modify the ACLs on a remote peer, Autonomous Database manages the ACLs on the remote peer independently.

To use different network ACLs on a remote Autonomous Database peer:

  1. On the primary database, on the Autonomous Database Details page, under Resources select Disaster recovery.
  2. Access the remote peer.

    The Disaster recovery information area shows the Peer Autonomous Database. The remote peer database by default has the same display name as the primary database, with an extension. For example, DBNAME_remote.

    Under Peer Autonomous Database, click the link to access a cross-region peer.

  3. On the remote peer database, edit the access control list.

    Before you change ACL the dialog shows a message indicating that ACLs on the peer database are syncing from the Primary database. For example:

    Description of adb_remote_peer_sync_acls.png follows

    See Configure Access Control Lists for an Existing Autonomous Database Instance for more information.

  4. Add, remove, or modify one or more ACLs.
  5. Click Save.

After you modify ACLs, the ACLs on the primary and on the remote peer are managed separately.

If you want to restart the synchronization of ACLs between the primary and the remote peer, you have two options:

  • Terminate the peer Autonomous Database and create a new cross-region disaster recovery peer database.

    See Disable a Cross-Region (Remote) Peer for details on terminating a remote peer database.

  • Contact Oracle Cloud Support and file a service request or contact your support representative.

Use the API

Provides links for details on using API operations to manage Backup-Based Disaster Recovery.

For information about using the API and signing requests, see REST APIs and Security Credentials.

For information about SDKs, see Software Development Kits and Command Line Interface.

Use these API operations to manage Disaster Recovery:

Use these Terraform APIs to manage Autonomous Database resources:

For information about Terraform, see Terraform Provider and for information about Terraform APIs, see Data Source: oci_database_autonomous_database.

Backup-Based Disaster Recovery Events

You can use Oracle Cloud Infrastructure events to respond when Autonomous Database changes its state due to a Backup-Based Disaster Recovery related event.

Autonomous Database events include the following:

  • Begin manual failover
  • End manual failover with failover result of success or failure.
  • Begin switchover
  • End switchover with switchover result of success or failure.

Based on events you can perform actions or send notifications. See Events and Notifications for a Standby Database for more information on using events and producing notifications.