Back Up and Recovery in Base Database Service
Backing up your database is critical to ensure the safety of your data. Oracle offers several methods for backing up your database.
The Oracle-managed automatic backups feature is the preferred method for backing up Oracle Cloud databases because you can easily configure backup settings using the Console. The automatic backups feature supports Recovery Service and Object Storage as the backup destination to provide you with a fully automated cloud backup solution. You do not need to perform any manual backups or backup storage administration tasks. You can also store backups in local storage. Each backup destination has its advantages and requirements that you should consider, as described below.
Recovery Service (Recommended)
- Backups are stored as protected databases in the Recovery Service.
- Durability: High
- Availability: High
- Back Up and Recovery Rate: High
- Advantages: High durability, performance, and availability.
For more information on Recovery Service, see About Oracle Database Autonomous Recovery Service.
Object Storage
- Backups are stored in the Object Storage.
- Durability: High
- Availability: High
- Back Up and Recovery Rate: Medium
- Advantages: High durability, performance, and availability.
For more information on Object Storage, see Overview of Object Storage.
Local Storage
- Backups are stored locally in the Fast Recovery Area of the DB system.
- Durability: Low
- Availability: Medium
- Back Up and Recovery Rate: High
- Advantages: Optimized back up and fast point-in-time recovery.
- Disadvantages: If the DB system becomes unavailable, the backup is also unavailable.
Currently, Oracle does not provide the ability to attach block storage volumes to a DB system, so you cannot back up to network attached volumes.
For unmanaged backups, you can use RMAN
or dbcli
, and you must create and manage your own Object Storage buckets for backups.
If you previously used
RMAN
or dbcli
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
work.
For detailed instructions on creating backups, see:
For detailed instructions on recovering from backups, see:
Required IAM Policy
To use Oracle Cloud Infrastructure, you must be granted security access in a policy by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment to work in.
If you're new to policies, see Getting Started with Policies and Common Policies.
Prerequisites
Review and ensure that the following prerequisites are met for the back up and recovery operation:
Recovery Service
For detailed information about Recovery Service prerequisites, see Configure Recovery Service.
Object Storage
- The DB system requires access to the Object Storage including connectivity to the applicable Swift endpoint. Oracle recommends using a service gateway with the VCN to enable this access. See VCN and Subnets.
- 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. See Managing Buckets.
- An auth token generated by OCI. You can use the Console or the IAM API to generate the password. See Managing User Credentials.
-
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 on Object Storage, see Overview of Object Storage.
General Information
Your database and 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 and Data Guard 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 DB system and database availability are restored.
In addition to the prerequisites listed, ensure that the following conditions are met to avoid backup failures:
- The database's archiving mode is set to
ARCHIVELOG
(the default). - The
/u01
directory on the database host file system has sufficient free space for the execution of backup processes. - The .bash_profile file for the oracle user does not include any
interactive commands (such as
oraenv
or one that could generate an error or warning message). - (For automatic backups) No changes were made to the default
WALLET_LOCATION
entry in the sqlnet.ora file. - No changes were made to
RMAN
backup settings by using standardRMAN
commands.
For more information on problems that can result from not following these guidelines, see Troubleshoot Backup Failures.
Managed Backup Features
The following information applies to managed backups configured using the Console or API.
Databases in a security zone compartment must have automatic backups enabled. For a full list of policies that affect Base Database Service resources, see Security Zone Policies.
Currently, the following two types of automatic backups are supported:
- Recovery Service: A centralized, fully managed, and standalone backup solution for databases.
- Object Storage: A secure, scalable, on-demand storage solution for databases.
To align with the Oracle recommended practice of using SYSBACKUP administrative privileges for backup and recovery operations, cloud automation creates a common administrative user named C##DBLCMUSER with the 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 operations.
Automatic Incremental and Archived Redo Log Backups
When you enable the Object Storage backup feature for a database, the service creates the following on an on-going basis:
- Weekly level 0 backup, generally created on a specified weekend day. A level 0 backup is the equivalent of a full backup. Note that in the Console, weekly level 0 backups appear in the list of backups with backup type "incremental", as do the daily level 1 backups.
- Daily level 1 backups, which are incremental backups created on each day for the six days following the level 0 backup day.
- Level 0 and level 1 backups are stored in Object Store and have an assigned OCID.
- Ongoing archived redo log backups (with a minimum frequency of every 60 minutes). The Last backup time field on the database details page in the OCI Console displays the time of the last archived redo logs. This backup differs from the level 0 and level 1 automatic backups in that it is based on log data and does not have an assigned OCID. The last archived redo log backup can be used to create a new database or to recover a database with minimal data loss.
Backup Retention
If you choose to enable automatic backups, you can choose from one of the provided retention periods or a custom policy. The system automatically deletes your incremental backups at the end of your chosen retention period.
- Bronze (14 days)
- Silver (35 days) (default)
- Gold (65 days)
- Platinum (95 days)
- Custom (User defined protection policy)
- 7 days
- 15 days
- 30 days (default)
- 45 days
- 60 days
Restore Options
The following restore options are available for the database.
- Restore to the latest: Restores the database to the last known good state with the least possible data loss.
- Restore to a timestamp: Restores the database to the timestamp specified.
-
Restore to SCN: Restores the database using the System Change Number (SCN) specified. This SCN must be valid.
Note
You can determine the SCN number to use either by accessing and querying your database host or by accessing any online or archived logs.
Protection Policies
Recovery Service uses protection policies to control database backup retention in Oracle Cloud.
Protection Policies provide automated retention management for protected databases, satisfying requirements for regulated environments. Each protected database must be associated with one protection policy.
A protection policy determines the maximum period (in days) allowed to retain backups created by Recovery Service. Based on your business requirements, you can assign separate policies for each protected database or use a single policy across all protected databases in a VCN.
For more information, see Managing Protection Policies.
Protected Databases
Protected database refers to an Oracle Cloud database that uses Recovery Service for backup operations.
For more information, see Managing Protected Databases.
Real-time Data Protection
Recovery Service offers real-time data protection so that you can recover a database within a few sub-seconds of a database failure.
Real-time protection is the continuous transfer of redo changes from a protected database to Recovery Service. This reduces data loss and provides a recovery point objective (RPO) near 0. This is an extra cost option.
For more information, see Real-time Data Protection.
Backup Deletion Options After Database Termination
When you terminate a database, all of its resources are deleted, along with any automatic backups. Managed backups using the Recovery Service and Object Storage destination will be deleted according to the retention policy options selected.
You can use the following options to retain managed database backups after the database is terminated. These options can also help restore the database from backups in case of accidental or malicious damage to the database.
- Retain backups according to the retention period: When a database is terminated, the automatic database backups associated with the terminated database and all of its resources will be removed at the end of the specified retention period.
- Retain backups for 72 hours, then delete: When a database is terminated, the automatic database backups associated with the terminated database and all of its resources will be retained for 72 hours and then deleted. The backups are retained for 72 hours to safeguard against accidental deletion by the user.
Backup Scheduling
For Recovery Service backups, the automatic backup process starts at any time or within the assigned window.
For Object Storage backups, the automatic backup process used to create level 0 and level 1 backups can run at any time within the daily backup window (between midnight and 6:00 AM). 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.
For Object Storage backups, the default backup window of 00:00 to 06:00 in the time zone of the DB system'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.
Consider the following factors while scheduling backups.
- Backup window time zone: Automatic backups enabled for the first time after November 20, 2018 on any database will run between midnight and 6:00 AM in the time zone of the DB system's region. If you have enabled automatic backups on a database before this date, the backup window for the database will continue to be between midnight and 6:00 AM UTC. You can create a My Oracle Support service request to have your automatic backups run in a backup window of your choice.
- Data Guard: In a Data Guard association, you can configure automatic backups and create backups of the primary database. However, you cannot configure automatic backups or create backups of the standby database. Also, after a switchover operation, you must again configure automatic backups for the database that has assumed the primary role in the Data Guard association.
- Retention period changes: If you shorten your database's automatic backup retention period in the future, existing backups falling outside the updated retention period are deleted by the system.
- Object Storage costs: Automatic backups incur Object Storage usage costs.
On-Demand Full Backups
You can create a full backup of your database at any time unless your database is assuming the standby role in a Data Guard association.
Standalone Backups
When you terminate a DB system or a database, all of its resources are deleted, along with any automatic backups. Managed backups using the Recovery Service and Object Storage destination will be deleted according to the retention policy options selected. Full backups remain in Object Storage as standalone backups. You can use a standalone backup to create a new database.
- The list of backups you see in the Console does not include any
unmanaged backups (backups created directly by using
RMAN
ordbcli
). - All backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.
Cancel a Running Full or Incremental Backup
You can cancel an ongoing backup, allowing you to free up system resources. As part of the Create Database workflow and independently (after the database has been created), you may enable automatic backup and select the desired backup destination. Depending on the backup destination selected, you may have one or more full backups and several incremental backups. Once any of these backups have started, you have the option to cancel them midway. You can cancel any running backup (automatic or standalone) from the Console or the API. You can cancel a manual backup, which is triggered when you click the Create backup button. You can also delete a canceled manual backup.
Backup and Restore from a Standby Database in a Data Guard Association
You can backup and restore from a standby database in a Data Guard association. By using this feature, you can offload backups to the standby database, thereby freeing up resources in the primary database.
Before you begin, note the following:
- You can use the Recovery Service or Object Storage to backup the standby databases.
- You can schedule automatic backups and configure retention periods and backup schedules on the standby database.
- You can create a database in another availability domain (AD) within the same region or a different region from a backup of the standby database.
- Backups can be configured on only the primary database, on only the standby database, or on both primary and standby databases. However, when configured, both the primary and standby databases must have the same backup destination.
- For backups in the Recovery Service, the primary database can be restored or recovered from the backups of either the standby database or the primary database. Similarly, the standby database can be restored or recovered from the backups of either the primary database or the standby database.
- For backups in the Object Storage, the primary database and standby database can be restored or recovered from their respective backups only.
- The backup destination of the primary database and standby database in a Data Guard association must be the same. For example, if the backup destination of the primary database is Recovery Service, then the backup destination of the standby database must also be Recovery Service. Similarly, if the backup destination of the standby database is Recovery Service, then the backup destination of the primary database must also be Recovery Service.
- Backup destination can be changed only after disabling the backup on either the primary or standby database in a Data Guard association. For example, if the backup destination of both the primary and standby databases is Object Storage and you want to change the backup destination of the primary database to Recovery Service, you must first disable the backup on the standby database.
- If automatic backup was configured on the primary, upon switchover, the backups would continue on the new standby database.
- If automatic backup was configured on the standby, upon failover, the backups will continue on the new primary database, and the backups will be disabled on the new standby database.
For detailed steps to configure automatic backups using the Console, see Configure Automatic Backups for a Standby Database.
Cross Region Restore
You can use an existing backup and restore it to create a database (out-of-place restore) across availability domains within the same region or in a different region using a backup created with Object Storage or Autonomous Recovery Service.
You can also restore a backup taken on either a database that was configured using host-based wallets (local wallets) or OCI Vault. For more information on database encryption keys, see Manage Encryption Keys.
The following prerequisites are required for cross region restore (within the same tenancy) for the Oracle Database Autonomous Recovery Service.
- VCN peering: Both the VCNs in local and remote regions must be peered across regions.
-
Add security rules on the source and target VCNs.
- Add Ingress rules on the source.
-
Click Add Ingress Rule, and add these details to set up a rule that allows HTTPS traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the VCN where the database resides.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 8005
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
Click Add Ingress Rule, and add these details to set up a rule that allows SQLNet traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the VCN where the database resides.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 2484
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
Click Add Ingress Rule, and add these details to set up a rule that allows HTTPS traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the target VCN.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 8005
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
Click Add Ingress Rule, and add these details to set up a rule that allows SQLNet traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the target VCN.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 2484
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
- Add Egress rules on the target. These are optional if the
egress traffic is opened for all IPs and ports.
-
Click Add Egress Rule, and add these details to set up a rule that allows HTTPS traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the source VCN.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 8005
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
Click Add Egress Rule, and add these details to set up a rule that allows SQLNet traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the source VCN.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 2484
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
Note
Ensure that the Recovery Service subnet is present in the source region and is attached to the source VCN. For more information, see Creating a Recovery Service Subnet in the Database VCN. - Add Ingress rules on the source.
- Perform DNS peering between local and remote VCNs.
Audit and Trace File Retention for Databases Using Automatic Backups
Oracle Database writes audit and trace files to your database's local
storage in the /u01
directory. These files are retained for 30 days by
default, though you can change this interval. Once a day, audit and trace files older
than 30 days (or the user-specified interval, if applicable) are discarded by a Oracle
Scheduler job. You can also disable the Scheduler job if you want to retain these files
permanently. Use the following dbcli
commands to make changes to this
Scheduler job.
-
To change the retention period from the default setting of 30 days:
dbcli update-database -in <dbName> -lr <number_of_days_to_retain_files>
For example:
dbcli update-database -in inventorydb -lr 15
-
To disable the daily discard Scheduler job for older audit and trace files:
dbcli update-schedule -i <schedulerID> -d
For example:
dbcli update-schedule -i 5678 -d
Use the API
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:
- ListBackups
- GetBackup
- CreateBackup
- DeleteBackup
- RestoreDatabase
- UpdateDatabase - To enable and disable automatic backups.
- CreateDbHome - For creating a DB system database from a standalone backup.
For the complete list of APIs for the Database service, see Database Service API.