Autonomous Recovery Service Checklist

 Utilizing the Autonomous Recovery Service (ARS) for your Oracle Databases in OCI is the best method for backing up your Oracle databases.  In this post I will go through the steps required to successfully implement this service.  To learn more about this service you can find the documentation here.

1. Ensure your tenancy's resource limits are adequate

Before implementing the ARS, 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 ARS. 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.

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

2. Verify the policies for the tenancy

A) Set root compartment policies for service

Tenancy Polices for ARS

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.

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

Group Policy Statement by Compartment

Policy Statement	Create In	Purpose
Allow group {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.

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 {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.

3. 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.

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.

4. 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".

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

1. Check your limits and quotas for the recovery service
2. Create the policies for the Recovery Service, and groups (users) to manage the recovery service
3. Create the subnet for the Recovery Service making sure you have the correct security settings, and the subnet has access to Oracle services
4. Register the subnet as the Recovery Service Subnet.