Autonomous Recovery Service Checklist

March 11, 2024 | 12 minute read
Bryan Grenn
Database, Infrastructure & Cloud Solutions Architect
Text Size 100%:

Utilizing the Autonomous Recovery Service  for your Oracle Databases in OCI is the best method for backing up your Oracle databases.

The documentation for configuring the Recovery Service can be found Here.

 In this post I will go through the steps required to successfully implement this service.  Below is a checklist of steps to get you started

1. Ensure the Autonomous Recovery Service is supported for your database Release

You can use Oracle Database Autonomous Recovery Service as the backup destination for Oracle Cloud databases provisioned with the following Oracle Database releases.

Oracle Database Edition and Version More Information

Oracle Database 19c Release 16 (19.16) or later

To use the Real-time data protection feature, your database must be provisioned with:

Oracle Database 19c Release 18 (19.18) or later

Oracle Database 21c Release 7 (21.7) or later

To use the Real-time data protection feature, your database must be provisioned with:

Oracle Database 21c Release 8 (21.8) or later

Oracle Database 23ai

To use the Real-time data protection feature, your database must be provisioned with:

Oracle Database 23ai Release 4 (23.4) or later

 

2. Ensure your COMPATIBLE inititialization parameter is current

Your COMPATIBLE parameter needs to be set to 19.0.0 or above in order to use the Autonomous Recovery Service.  This parameter is typically not updated during the upgrade process, so it is important to ensure that it is set to a high enough value.

Below is the type of mesage you will see if it is not set correctly.

Database job: Failure. DBAAS-10327 : Minimum required COMPATIBLE version is 19.0.0. Current database COMPATIBLE version is: 12.1.0.2.0.

 

3. Ensure your tenancy's resource limits are adequate

Before implementing the Recovery Service, you first must see what the resource settings are in your tenancy. You want to make sure that the "Space Used for Recovery Window (GB)" and "Protected Database Count" allow for the number of databases, and backup size of the databases you want to utilize the service for.

Below is what you would see for the Recovery Service. This is a screen shot from my free tenancy.  In your tenancy you should see what the current limits are.  When looking at the root compartment, this will show you the Limits and usage for the whole tenancy.

Recovery Service Limits

If you need to increase the limits for your tenancy click on the 3 dots to the right of the limit you want to increase. It will bring up a choice to "Open Support Request".  After choosing "Open Support Request" you will see a window that allows you to request a limit increase for your tenancy.

NOTE: There is a second choice when clicking on the 3 dots to "Create Quota Policy Stub". Using the stub displayed you can limit the quota of specific compartments.  This can be used to limit the usage for your "dev" compartment for example, ensuring there is space within your limits for production

 

4. Verify the policies for the tenancy

A) Set root compartment policies for service

 

Tenancy Polices for Recovery Service  
Policy Statement Purpose
   

Allow service database to manage recovery-service-family in tenancy
 
Enables the OCI Database Service to access protected databases, protection policies, and Recovery Service subnets within your tenancy.

Allow service database to manage tagnamespace in tenancy
 
Enables the OCI Database Service to access the tag namespace in a tenancy.

Allow service rcs to manage recovery-service-family in tenancy
 
Enables Recovery Service to access and manage protected databases, Recovery Service subnets, and protection policies within your tenancy.

Allow service rcs to manage virtual-network-family in tenancy
 
Enables Recovery Service to access and manage the private subnet in each database VCN within your tenancy. The private subnet defines the network path for backups between a database and Recovery Service.

Allow group admin to manage recovery-service-family in tenancy
 
Enables users in a specified group to access all Recovery Service resources. Users belonging to the specified group can manage protected databases, protection policies, and Recovery Service subnets.

 

NOTE: In Policy builder if you choose "Ability do do all things with Autonomous Recovery Service" the policy statements will be added to the policy automatically

 

                             Recovery Service Policies     

    

B) Allow users (in group) to manage the Recovery Service

Group Policy Statement by Compartment  
Policy Statement Create In Purpose
   

Allow group '{identity domain}'/'{group name}' to manage recovery-service-policy in compartment {location}
 
Compartment that owns the protection policies. Enables all users in a specified group to create, update, and delete protection policies in Recovery Service.

 

NOTE: In Policy builder if you choose "Let users manage protection policies in Autonomous Recovery Service" and chose the correct "Identity domain", "Group" and "location" it will create the statement for you.

 

C) Allow users (in group) to manage the required subnet for the Recovery Service

 

Group Policy Statement by Compartment  
Policy Statement Create In Purpose
   

Allow Group '{identity domain}'/'{group name}' to manage recovery-service-subnet in compartment {location}
 
Compartment that owns the Recovery Service subnets. Enables all users in a specified group to create, update, and delete Recovery Service subnets.

 

NOTE: In Policy builder if you choose "Let users manage Autonomous Recovery Service subnets" and chose the correct "Identity domain", "Group" and "location" it will create the statement for you.

 

5. Additional Policies for Multicloud (Oracle Database@Azure at this point)

Create and assign this policy for Oracle Databases that run in Microsoft Azure environment to access Recovery Service. ORACLEDBATAZURE indicates the service name for Oracle Database@Azure.

 

Copied to Clipboard
Error: Could not Copy
Copied to Clipboard
Error: Could not Copy
<em>    Allow service database to use organizations-assigned-subscription in tenancy where target.subscription.serviceName = 'ORACLEDBATAZURE'</em>

Alternatively, use this policy to assign the permissions for a specific subscription ID linked with Microsoft Azure. SubscriptionId is the placeholder for the specific service subscription ID.

 

Copied to Clipboard
Error: Could not Copy
Copied to Clipboard
Error: Could not Copy
<em>     Allow service database to use organizations-assigned-subscription in tenancy where target.subscription.id = '<<kbd>SubscriptionId</kbd>>'</em>

 

6. Configure Network Resources for Recovery Service

The Recovery Service uses Private endpoints to control backup traffic between your database and the recovery service.  Below is the architecture.

Recovery Service Architecture

 

Each Recovery service subnet needs to be created within the VNC where your database resides.  

The minimum size of the subnet is /24 (256 IP addresses).  You can create a new subnet, or use an preexisting subnet in you database VCN.  This subnet must be IPv4.

Security rules (implemented through Security Lists, or Network Security Groups) for the private subnet must include stateful ingress rules to allow destination ports 8005 and 2484.

NOTE: You can use a public subnet, but it is not recommended for security reasons.

This private subnet must be registered as a Recovery Service Subnet.

Checklist for Security rules (Security List or NSG)

1. Rule 1 - Ingress. Allow HTTPS traffic from anywhere

 

  • Stateless: No (All rules must be stateful)
  • Source Type: CIDR
  • Source CIDR : CIDR of the VCN where the database resides
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 8005

 

2. Rule 2 - Ingress. Allow SQLNet traffic from anywhere

 

  • Stateless: No (All rules must be stateful)
  • Source Type: CIDR
  • Source CIDR : CIDR of the VCN where the database resides
  • IP Protocol: TCP
  • Source Port Range: All
  • Destination Port Range: 2484

NOTE: If your VCN restricts network traffic between subnets, ensure to add an egress rule for ports 2484, and 8005 from the database subnet to the Recovery Service subnet that you create.

 

3. Register the subnet with recovery service

 

Under Oracle Database --> Database Backups you need to click on "Recovery Service Subnets" and register the Recovery Service Subnet.

 

Recover Service Subnet

 

 Ensure the Recovery Service Subnet can communicate with Oracle services.

The Recovery Service Subnet that you registered needs to communicate with the Recovery Service. In order to access the service, the routing table for this subnets needs to include "All IAD Services In Oracle Services Network".

 

7. Ensure your database has TDE fully configured

When using the Autonomous Recovery Service, you must have your database fully TDE encrypted.  For new databases that are born in the cloud, this should already be done.  But if you creating a stub database in OCI and migrating a database to an Oracle Database Service from on-premises, or somewhere else, you might not meet all the criteria.  For these databases you should verify that you meet the prerequisites for a backing up to the recovery service.  I have a blog post you can find here that will outline what to check for with queries to execute.

From a high level you should meet these 3 criteria.

  • You need to have WALLET_ROOT configured in the database. If you are still using sqlnet.ora you need to use the tooling (see below) to properly set WALLET_ROOT for all databases that will be utilizing the Recovery Service.  Note: Setting the ENCRYPTION_WALLET_LOCATION in the sqlnet.ora is not supported and will be depricated.

           dbaascli tde enableWalletRoot - enable wallet_root spfile parameter for existing database.

Copied to Clipboard
Error: Could not Copy
Copied to Clipboard
Error: Could not Copy
<tt>           Usage: dbaascli tde enableWalletRoot --dbname <value> [--dbRestart <value>] [--precheckOnly] 
                     Where:
                          --dbname - Oracle database name.
                          [--dbRestart - database restart option. Valid values : full|rolling ]
                          [ --precheckOnly - run the prerequisite checks and report the results. ]
                          [--resume - to resume the previous operation]

           <big><strong> NOTE: In order for this change to take effect you need to have a restart of the database.
                The default is a rolling bounce of the database.
</strong></big></tt>
  • You need to have an encryption key set for the CDB and ALL PDBs in your database.
  • ALL tablespaces must be TDE encrypted before executing your first backup.

8. Turn off any manual operational backups

In some cases, OCI users are executing manual operationational backups. These are backups which are run outside the tooling and support a point-in-time recovery (non-KEEP backups).

If you are running any of these types of operational backups, it is critical that you turn them off at this point.  Executing operational backups to two different locations can cause issues with both backups.

NOTE: if you are using the tooling for object storage backups, and switch to the Recovery Service, the switchover will be automated by the tooling, and all of the previous backups will remain available.

If all these pieces are in place you should be ready to successfully configure your database backups to go the Recover Service for backup.

 

Short checklist

 

    Check your release version and availablility for the Recovery Service

    Check the COMPATIBLE inititialization parameter 

    Check your limits and quotas for the Recovery Service

    Create the policies for the Recovery Service

    Create the policies for the Group (users) to manage the Recovery Service

    Create the subnet for the Recovery Service

    Ensure ingress/egress ports are configured between the DB hosts and the Recovery Service

    Ensure the Recovery Service subnet has access to Oracle Services

    Register the subnet as the Recovery Service Subnet

    Ensure you are using WALLET_ROOT for the location of the encryption wallet

    Ensure encryption keys are set for the CDB and all PDBs

    Ensure all tablespaces are TDE encrypted

    Disable any existing operational backups that were not executed through the tooling

 

NOTE: If you follow this checklist and the configuration of the Autonomous Recovery Service fails onboarding your first database, follow the steps below when you open up an SR

1.  Open the SR for the database service you are using

                    -  Oracle Cloud Infrastructure -Exadata Cloud Service

                            Problem type should be               Patching issues & Tools --> Cloud Tools

 

                    -  Oracle Database Cloud Service

                            Problem type should be                DBCS Tools --> Using Cloud Toolset

                    -  Autonomous Database Dedicated

                            Problem type should be                Database Administration --> Backup and Recovery

2. Include the following information when opening up the SR.

  •     Workrequest error OCID that appeared in the console
  •     Database OCID
  •     VM Cluster OCID
  •     Screenshots of the error
  •     Region

 

Bryan Grenn

Database, Infrastructure & Cloud Solutions Architect

Bryan Grenn works as a specialist in the North America Engineered Systems sales organization.The organization’s mission is to provide unparalleled expertise to enhance the customer experience with simple, comprehensive and complete architectural solutions that are tailored to their needs.

 

Show more

Previous Post

GCB Bank modernizes core banking systems with Oracle Exadata and Zero Data Loss Recovery Appliance

Donna Cooksey | 5 min read

Next Post


Oracle Database Backup Cloud Service checklist

Bryan Grenn | 7 min read
Oracle Chatbot
Disconnected