Manage Database Backup and Recovery on Oracle Exadata Database Service on Dedicated Infrastructure

Learn how to work with the backup and recovery facilities provided by Oracle Exadata Database Service on Dedicated Infrastructure.

Oracle Recommended Options to Perform Backup and Recovery Operations

Oracle offers the following options for Oracle Database Backup and Recovery operations. These options are mutually exclusive.

Note

A hybrid configuration, that is, mixing the options is not supported. Mixing the options will break automation.

Option 1: Oracle Managed Backups

Oracle managed backups are entirely managed by Exadata Cloud Infrastructure (ExaDB-D) or Exadata Cloud@Customer (ExaDB-C@C) based on a one-time configuration. Besides being fully integrated into ExaDB-D or ExaDB-C@C cloud services Control Plane, these backups can also be accessed through OCI APIs. Oracle recommends this approach.

  • The dbaascli database backup and dbaascli database recover commands can be used in conjunction with the automated backups for certain operations. For more information, see dbaascli database backup and dbaascli database recover.
  • Customers are allowed to query RMAN views or issue RMAN restore and recovery commands, for example, table, datafile, or tablespace recovery commands.
    Note

    Do not use RMAN configuration to change any of the pre-tuned cloud RMAN settings.

Option 2: User Configured Backups

Customers can also configure backups from the host using the dbaascli database backup and dbaascli database recover commands. These backups, however, are not synchronized with the Control Plane nor are they integrated with the OCI APIs. Also, neither management nor lifecycle operations on these backups are supported from the service Control Plane console. Hence, this is not a recommended approach.

This approach is useful when direct access to Backup destinations is required to perform certain tasks. Accessing the OSS bucket, for example, to replicate backups across regions or monitor Backup Destinations.

If customers configure backups to Object Storage using RMAN without using the OCI Control Plane or OCI APIs, customers are responsible for manually configuring TDE Wallet backups. By default, Oracle cloud automation cleans up archive log files every 24 hours. When you use RMAN to perform manual backups, there is a risk of the archive logs being deleted. Refer to dbaascli database backup for information on how to configure the archive log cleanup. The recommendation is to use Oracle managed backups.

For more information, see User Configured Backup.

Option 3: Backups using RMAN

Backups can be directly taken using RMAN with customer-owned customized scripts. Oracle, however, does not recommend this approach.

It is not recommended to use RMAN backups in conjunction with Oracle Managed Backups or User Configured Backups.

Who can use this option:
  • Customers who want to maintain their existing RMAN backup/restore scripts.
  • Customers who want to configure backups from Standby database in Data Guard environments to offload the backup workload to Standby.

ExaDB-D:

If you plan to backup using RMAN, then you must unregister the database from backup automation. For more information, see Disabling Automatic Backups to Facilitate Manual Backup and Recovery Management.

Managing Exadata Database Backups

Automatic Exadata database backups are managed by Oracle Cloud Infrastructure. You configure this by using the Console or the API.

For unmanaged backups, see Managing Exadata Database Backups by Using bkup_api.

There are two destinations possible for automatic Exadata database backups: Autonomous Recovery Service, or Oracle Object Storage.

Note

If you previously used bkup_api to configure backups and then you switch to using the Console or the API for backups:

  • A new backup configuration is created and associated with your database. This means that you can no longer rely on your previously configured unmanaged backups to protect your database.
  • bkup_api uses cron jobs to schedule backups. These jobs are not automatically removed when you switch to using managed backups.

Managed Backup Types and Usage Information

There are two types of automatic Exadata database backups: Autonomous Recovery Service, and Oracle Object Storage.

The database and infrastructure (the VM cluster or DB system) must be in an “Available” state for a backup operation to run successfully. Oracle recommends that you avoid performing actions that could interfere with availability (such as patching operations) while a backup operation is in progress. If an automatic backup operation fails, the Database service retries the operation during the next day’s backup window. If an on-demand full backup fails, you can try the operation again when the Exadata Cloud Infrastructure instance and database availability are restored.

When you enable the Automatic Backup feature, either service creates daily incremental backups of the database to the selected Backup Destination.

If you choose to enable automatic backups, you can control the retention period. The system automatically deletes backups when the assigned retention period is expired.

Object Storage Backup retention period: 7, 15, 30, 45, 60. Default: 30 days.

The automatic backup process starts at any time during your daily backup window. You can optionally specify a 2-hour scheduling window for your database during which the automatic backup process will begin. There are 12 scheduling windows to choose from, each starting on an even-numbered hour (for example, one window runs from 4:00-6:00 AM, and the next from 6:00-8:00 AM). Backups jobs do not necessarily complete within the scheduling window.

The default backup window of 00:00 to 06:00 in the time zone of the Exadata Cloud Infrastructure instance's region is assigned to your database if you do not specify a window. Note that the default backup scheduling window is six hours long, while the windows you specify are two hours long.

Autonomous Recovery Service protection policy:
  • Bronze :14 days
  • Silver: 35 days
  • Gold: 65 days
  • Platinum: 95 days
  • Custom defined by you
  • Default: Silver - 35 days

The automatic backup process starts at any time or within the assigned window.

Note

  • Data Guard: You can enable the Automatic Backup feature on a database with the standby role in a Data Guard association.
  • Backup Retention Changes: If you shorten your database's backup retention period or your protection policy in the future, existing backups falling outside the updated retention period are deleted by the system.
  • Backup Storage Costs: Automatic backups incur storage usage costs for either Autonomous Recovery Service or Object Storage depending on the backup destination selected.

You can create a full backup of your database at any time using either service.

When you terminate an Exadata Cloud Service instance database, all of its resources are deleted. Managed backups using the Object Storage destination will be deleted, and Managed backups using the Autonomous Recovery Service will be deleted according to the deletion option selected. Standalone backups created in Object Storage will remain after the database is terminated and must be manually deleted. You can use a standalone backup to create a new database.

To align with the Oracle recommended practice of using SYSBACKUP administrative privilege for Backup and Recovery operations, cloud automation creates a common administrative user C##DBLCMUSER with SYSBACKUP role at the CDB$ROOT container level. Backup and Recovery operations are therefore performed with the user having the least required privileges. Credentials for this user are randomly generated and securely managed by cloud automation. If the user is not found or is LOCKED and EXPIRED, then cloud automation will recreate or unlock this user during the backup or recovery operation. This change in the cloud automation is made starting with dbaastools version 21.4.1.1.0.

Default Backup Channel Allocation

The default settings for database backup channels when using "Oracle Managed Backup" or "User Configured Backup"

When a database is configured for backup using "Oracle Managed Backup" or "User Configured Backup", the tooling uses "default" for the backup channels. When default is used, dbaas will determine the number of channels to allocate at the time the backup or restore command is executed. The number of channels allocated is determined by the OCPU count of the node. The following table provides the values used and the OCPU range, both the OCPU and the channel values are per node. Restore operations are prioritized. The cluster-wide total channel count is the per node value multiplied by the number of nodes. The automation uses the SCAN to distribute RMAN channels across all nodes in the cluster.

OCPUs Per Node Formula Backup Channels Allocation Per Node Restore Channels Allocation Per Node
Less than or equal to 12 OCPU <= 12 2 4
Greater than 12 and less than or equal to 24 OCPU > 12 and OCPU <= 24 4 8
Greater than 24 OCPU > 24 8 16

If needed, a static per node value can be set by using the DBAASCLI getConfig/configure to generate a bckup cfg and setting the parameter bkup_channels_node to the number of channels per node desired.

Valid values are 1 - 32: The total channel count will be the value times the number of nodes. This value cannot exceed the limit of 255 channels. A value of default for bkup_channels_node sets OCPU channel based allocation.

Prerequisites for Backups on Exadata Cloud Infrastructure

Recovery Service

Ensure that your tenancy is configured to use Recovery Service.

Table 5-7 Review the prerequisite tasks before you use Recovery Service as the automatic backup destination

Task More Information Required or Optional

Create IAM policies

Policies to Enable Access to Recovery Service and Related Resources

Required

Configure network resources and register a Recovery Service subnet

Creating a Recovery Service Subnet in the Database VCN

Required

Create protection policies

Review Protection Policies for Database Backup Retention

Optional

For more information about Recovery Service, see Overview of Oracle Database Autonomous Recovery Service.

Object Storage

  • The Exadata Cloud Service instance requires access to the Oracle Cloud Infrastructure Object Storage. Oracle recommends using a service gateway with the VCN to enable this access. For more information, see Network Setup for Exadata Cloud Infrastructure Instances. In that topic, pay particular attention to:
  • An existing Object Storage bucket to use as the backup destination. You can use the Console or the Object Storage API to create the bucket. For more information, see Managing Buckets.
  • An auth token generated by Oracle Cloud Infrastructure. You can use the Console or the IAM API to generate the password. For more information, see Working with Auth Tokens.
  • The user name specified in the backup configuration file must have tenancy-level access to Object Storage. An easy way to do this is to add the user name to the Administrators group. However, that allows access to all of the cloud services. Instead, an administrator should create a policy like the following that limits access to only the required resources in Object Storage for backing up and restoring the database:
    Allow group <group_name> to manage objects in compartment <compartment_name> where target.bucket.name = '<bucket_name>'
    Allow group <group_name> to read buckets in compartment <compartment_name>

    For more information about adding a user to a group, see Managing Groups. For more information about policies, see Getting Started with Policies.

Using the Console to Manage Backups

You can use the Console to enable automatic incremental backups, create full backups on demand, and view the list of managed backups for a database. You can also use the Console to delete manual (on-demand) backups.

Note

  • The list of backups you see in the Console does not include any unmanaged backups (backups created directly by using bkup_api).
  • All backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.
  • Backups for a particular database are listed on the details page for that database. The Encryption Key column displays either Oracle-Managed Key or a key name if you are using your own encryption keys to protect the database. See Backing Up Vaults and Keys for more information.
Note

Do not delete any necessary encryption keys from the vault because this causes databases and backups protected by the key to become unavailable.

To configure automatic backups for a database

To create an on-demand backup of a database

To view backup status

To cancel a backup

To delete full backups from Object Storage

To delete standalone backups from Object Storage

  1. Open the navigation menu. Click Oracle Database, then click Standalone Backups under Resources.
  2. In the list of standalone backups, find the backup you want to use to delete.
  3. Click the Actions menu for the backup you are interested in, and then click Delete.
  4. In the Delete dialog, click Delete to confirm the backup deletion.

To designate Autonomous Recovery Service as a Backup Destination for an Existing Database

Recovering an Exadata Database from Backup Destination

This topic explains how to recover an Exadata database from a backup stored in either Object Storage or Autonomous Recovery Service by using the Console or the API.

  • Object Storage service is a secure, scalable, on-demand storage solution in Exadata Cloud Infrastructure.
  • OracleDatabase Autonomous Recovery Service is a centralized, fully managed, and standalone backup solution for Oracle Cloud Infrastructure (OCI) databases.

For more information about backing up your databases to Object Storage, see Managing Exadata Database Backups.

Using the Console to restore a database

You can use the Console to restore the database from a backup in a backup destination that was created by using the Console.

You can restore to:
  • Restore to latest
  • Restore to a timestamp
  • Restore to SCN
Note

The list of backups you see in the Console does not include any unmanaged backups (backups created directly by using bkup_api ).
To restore a database

Managing Exadata Database Backups by Using bkup_api

You can use Exadata's backup utility, bkup_api, to back up databases on an Exadata Cloud Infrastructure instance to an existing bucket in the Oracle Object Storage service and to the local disk Fast Recovery Area.
Note

bkup_api is deprecated equivalent dbaascli commands are listed for each bkup_api command

For backups managed by Oracle Cloud Infrastructure, see Managing Exadata Database Backups.

This topic explains how to:

  • Create a backup configuration file that indicates the backup destination, when the backup should run, and how long backups are retained. If the backup destination is Object Storage, the file also contains the credentials to access the service.
  • Associate the backup configuration file with a database. The database will be backed up as scheduled, or you can create an on-demand backup.
Note

You must update the cloud-specific tooling on all the compute nodes in your Exadata Cloud Infrastructure instance before performing the following procedures. For more information, see Updating an Exadata Cloud Service Instance.

Default Backup Configuration

Description of the default backup configuration that follows Oracle best practice guidelines.

The backup configuration follows a set of Oracle best-practice guidelines:

  • Full (level 0) backup of the database followed by rolling incremental (level 1) backups on a seven-day cycle (a 30-day cycle for the Object Storage destination).
  • Full backup of selected system files.
  • Automatic backups daily at a specific time set during the database deployment creation process.

Retention period:

  • Both Object Storage and local storage: 30 days, with the 7 most recent days' backups available on local storage.
  • Object Storage only: 30 days.
  • Local storage only: Seven days.

Encryption:

  • Both Object Storage and local storage: All backups to cloud storage are encrypted.
  • Object Storage only: All backups to cloud storage are encrypted.

To create a backup configuration file

To create an on-demand backup

To remove the backup configuration

To delete a local backup

To delete a backup in Object Storage

Using the API to Manage Backup and Recovery

Using the API to manage backups

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 database backups:

For the complete list of APIs for the Database service, see Database Service API.

Alternative Backup Methods

Learn about alternative backup methods that are available in addition to the OCI Console.

Backup for databases on Exadata Cloud Infrastructure can be accomplished through several methods in addition to the automatic backups configured in the console. Generally, the console (or the OCI API / CLI that correspond to it) is the preferred method as it provides the simplest and most automated method. In general, it is preferable to leverage the OCI Console, OCI API, or OCI Command-Line over alternative management methods. However, if required actions cannot be completed through the preferred methods, two other options are available to manually configure backups: bkup_api and Oracle Recovery Manager (RMAN).

Note

bkup_api will be deprecated in a future release. Use the dbaascli database backup, dbaascli pdb backup, dbaascli database recover, and dbaascli pdb recover commands to backup and recover container databases and pluggable databases. For more information, see User Configured Backup.

RMAN is the backup tool included with the Oracle Database. For information about using RMAN, see the Oracle Database Backup and Recovery User's Guide for Release 19. Using RMAN to back up databases on Exadata Cloud Infrastructure provides the most flexibility in terms of backup options, but also the most complexity.

Note

While using RMAN for restoring databases backed up through any method described herein is considered safe, RMAN should NEVER be used to set up backups in conjunction with either console (and OCI API / CLI), nor in conjunction with bkup_api. If you choose to orchestrate backups manually leveraging RMAN, you should not use either console automated backups, nor should you use bkup_api. You must first completely disable console based automated backups. For more information, see Disabling Automatic Backups to Facilitate Manual Backup and Recovery Management.

The bkup_api method offers a middle ground between RMAN and console automated backups in terms of flexibility and simplicity. Use bkup_api if needed functionality is not supported with console automated backups, but when you wish to avoid complexity of using RMAN directly. In certain cases, bkup_api can be used to modify the console automated backup configuration, but this is not generally the case. Generally, bkup_api must be used instead of enabling backups in the console.

Disabling Automatic Backups to Facilitate Manual Backup and Recovery Management

Backups, configured in the Exadata Cloud Infrastructure console, API or bkup_api work for a variety of backup and recovery use cases. If you require use cases not supported by the cloud-managed backups, then you can manage database backup and recovery manually, using the Oracle Recovery Manager (RMAN) utility. For information about using RMAN, see the Oracle Database Backup and Recovery User's Guide for Release 19.

Managing backup and recovery, using RMAN, on Exadata Cloud Infrastructure requires taking full ownership of both database and archive log backups, and the cloud-managed backups should no longer be used. Before manual backups are started, the cloud-managed backup functionality should be disabled. This is needed so the cloud backup jobs do not purge archive logs before they are manually backed up and do not conflict with the manual backups.

You can use the bkup_api utility to disable cloud-managed backups, including disabling the automatic archive log purge job, by following this procedure:

Note

If you execute these steps, then the automation will no longer purge/backup the archive logs in the FRA for the database.
  1. Connect as the opc user to the first compute node.

    For detailed instructions, see Connecting to a Compute Node with SSH.

  2. Start a root-user command shell:
    sudo -s
  3. Use the bkup_api get config command to generate a file containing the current backup settings for the database deployment:
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    Where:
    • filename is an optional parameter used to specify a name for the file that is generated
    • dbname is the database name for the database that you want to act on
  4. Edit the parameter values in the generated file to change the following parameters.
    This will remove the backup crontab entries and disable all automatic backups. If the values are set to yes, then set to no.
    bkup_cron_entry=no
    bkup_archlog_cron_entry=no
    bkup_nfs=no
    bkup_oss=no
    bkup_local=no
  5. Use the bkup_api set config command to update the backup settings using the file containing your updated backup settings:
    /var/opt/oracle/bkup_api/bkup_api set config --file=filename --dbname=dbname
    Where:
    • filename is an optional parameter used to specify a name for the file that is generated
    • dbname is the database name for the database that you want to act on

    The job to set the configuration will take several minutes to complete.

  6. You can use the bkup_api configure_status command to check the status of the configuration update:
    /var/opt/oracle/bkup_api/bkup_api configure_status --dbname=dbname
    Where:
    • dbname is the database name for the database that you want to act on

    The Configure backup status starts as running and then moves to finished when complete.

  7. Run the bkup_api get config command again and verify the settings listed above are set to no.
    /var/opt/oracle/bkup_api/bkup_api get config [--file=filename] --dbname=dbname
    Where:
    • filename is an optional parameter used to specify a name for the file that is generated
    • dbname is the database name for the database that you want to act on
    Note

    After making these changes, no backups, including archive log backups, are made by the cloud automation. Ensure that manual RMAN backups are in place to avoid filling the archive log location.
    Note

    Changes made using the bkup_api command are not reflected in the Oracle Exadata Database Service on Dedicated Infrastructure console.
  8. Exit the root-user command shell:
    exit

Recovering a Database Using Oracle Recovery Manager (RMAN)

If you backed up your database using bkup_api, then you can manually restore that database backup by using the Oracle Recovery Manager (RMAN) utility. For information about using RMAN, see the Oracle Database Backup and Recovery User's Guide for Release 19.

Note

While recovering using RMAN is safe, you must not use RMAN to initiate backups or edit backup setting in conjunction with either backup_api usage or in conjunction with automated console backups. Doing so could result in conflicting conditions or over-writes of settings, and backups may not execute successfully.