MCP Server for Autonomous Recovery Service

Wouldn't it be nice if I could just use AI and ask my tenancy to tell me about my Autonomous Recovery Service database backups ? I want to simply ask questions like ....

• List the databases that are actively using the recovery service in my tenancy and include their status, how much storage they are using, where there are any issues and break it down by both compartment and tag if tags are assigned.

• List out the databases that I have and look at the usage for the last 30 days.. Based on that usage give a line chart showing my space usage by database and based on the current growth show what the project usage will be for the next year.

• Using the tags create a pie chart showing the space usage for all of my backups and show the usage for each tag.

Well you can and the screenshot below is just part of the answer I got. !!

Thanks to Harini Gavisiddappa who created an MCP server within the Oracle MCP server github project you can do just that.

You can find the project at https://github.com/oracle/mcp

Installing

Here is the streamlined path to getting this running on your local Windows environment.

I chose putting it on my windows environment because I love using the Claude Chat tool so I can ask questions in a UI and get nicely formatted reports/output back.

Phase 1: Repository & Environment Setup

A) Download repository onto my PC

We start by pulling the source from the [Oracle MCP repository](https://github.com/oracle/mcp/tree/main/src/oci-recovery-mcp-server).

git clone [https://github.com/oracle/mcp.git](https://github.com/oracle/mcp.git) cd mcp

B) Initialize a scoped Python 3.13 environment

 To keep the footprint small and the execution fast, we’ll use `uv` for our Python toolchain.

uv venv --python 3.13 Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process .\.venv\Scripts\activate

C) Install the Recovery Server in development mode

cd src\oci-recovery-mcp-server uv pip install -e .

Phase 2: Identity & Access Management

Before the server can bridge to your tenancy, you need an active OCI session. This ensures the MCP server inherits your existing IAM permissions.

# Authenticate your session oci session authenticate --region us-ashburn-1 # Verify the token is active oci session validate --profile DEFAULT

Phase 3: Client Integration

{ "mcpServers": { "oracle-recovery": { "command": "uv", "args": [ "--directory", "C:\\ocimcp\\mcp", "run", "oracle.oci-recovery-mcp-server" ], "env": { "OCI_CONFIG_PROFILE": "DEFAULT", "FASTMCP_LOG_LEVEL": "ERROR" } } } }

Phase 4: Validation

Restart your client. You should now see the oracle-recovery toolset available. You can verify the connection immediately with a simple natural language query:

Now that it is installed, let's see what it can do

**************************************************

Question 1

List the databases that are actively using the recovery service in my tenancy and include their status, how much storage they are using, where there are any issues and break it down by both compartment and tag if tags are assigned.

Total databases

8

2 compartments

Storage used

354.6 GB

all databases

Protected

4

healthy, within SLA

Alert

4

recovery window = 0

Prod_databases — 2 databases · 139.9 GB

db19vdb19v_837_iad

Alert

20.3 GB used  ·  est. 14.6 GB  ·  14-day policy

Org: HR · Prod

Recovery window 0 of 14 days — redo logs not streaming or recently enrolled

tt2srctt2src_iad1mz

Protected

119.6 GB used  ·  est. 112.9 GB  ·  14-day policy

Org: Finance · Prod

14.3d retention · redo enabled

Nonprod_databases — 6 databases · 214.7 GB

db23cdb23c_npb_iad

Alert

3.0 GB used  ·  est. 9.1 GB  ·  14-day policy

Org: Finance · Pre-prod

⚠ Unprotected window: 70.5 days — no recent backup activity. Requires immediate attention.

ORCL_TESTORCL

Alert

4.1 GB used  ·  est. 11.3 GB  ·  14-day policy

Environment: Trial

⚠ Unprotected window: 24.9 days — recovery point significantly stale.

clprotclprot

Alert

10.5 GB used  ·  est. 22.1 GB  ·  14-day policy

Fleet agent managed

Recovery window 0 of 14 days · retention = 1 sec · min recovery needed 21 days

db23aidb23ai_6rm_iad

Protected

75.6 GB used  ·  est. 68.1 GB  ·  14-day policy

Org: Finance · Dev

15.0d retention · policy locked 2023-11-16

test2test2_rjh_iad

Protected

77.2 GB used  ·  est. 74.6 GB  ·  35-day policy

Org: HR · Dev

35.8d retention · redo enabled

demodbdemodb_tfj_iad

Protected

44.4 GB used  ·  est. 42.7 GB  ·  35-day policy

No Oracle-Standard tags

35.9d retention

By tag — Oracle-Standard · Org

Org	Databases	Storage	Status
Finance	4	198.2 GB	2 ok2 alert
HR	2	97.5 GB	1 ok1 alert
Untagged	3	59.0 GB	1 ok2 alert

By tag — Oracle-Standard · Environment

Environment	Databases	Storage	Status
Prod	2	139.9 GB	1 ok1 alert
Dev	2	152.8 GB	2 ok
Pre-prod	1	3.0 GB	1 alert
Trial	1	4.1 GB	1 alert
Untagged	2	54.9 GB	1 ok1 alert

**************************************************

 Question 2

List out the databases that I have and look at the usage for the last 30 days.. Based on that usage give a line chart showing my space usage by database and based on the current growth show what the project usage will be for the next year.

Question 3

Using the tags create a pie chart showing the space usage for all of my backups and show the usage for each tag.

Summary:

Above are some examples of what you can do with the new OCI Recovery Service MCP server with Claude.

Below is a list of the tools available to you to use.

Here are the 19 tools available through the Recovery Service MCP server, grouped by what they do:

Protected Databases

• list_protected_databases — list databases enrolled in Recovery Service, with metrics and subnet details, filtered by compartment, policy, lifecycle state, etc.
• get_protected_database — get full details for a single protected database by OCID
• summarize_protected_database_health — count of healthy / warning / alert / unknown databases in a compartment
• summarize_protected_database_backup_destination — how databases in a compartment are backed up (Recovery Service vs other destinations)
• summarize_protected_database_redo_status — how many databases have redo transport on or off

Protection Policies

• list_protection_policies — list policies in a compartment
• get_protection_policy — get a single policy by OCID

Recovery Service Subnets

• list_recovery_service_subnets — list subnets in a compartment
• get_recovery_service_subnet — get a single subnet by OCID

Backups

• list_backups — list backups with flexible filters and optional auto-paging
• get_backup — get a single backup by OCID

Metrics

• get_recovery_service_metrics — time-series metrics for a compartment or single database; supported metrics are SpaceUsedForRecoveryWindow, ProtectedDatabaseSize, ProtectedDatabaseHealth, and DataLossExposure; resolutions of 1m, 5m, 1h, 1d; aggregations of mean, sum, max, min, count

Storage Summaries

• summarize_backup_space_used — total backup space in GB across databases in a compartment
• summarize_protected_database_backup_destination — breakdown by backup destination type

DB Systems & Homes (for enrollment context)

• list_databases — list databases across DB Homes in a compartment, with backup settings and linked protection policy
• list_db_homes — list DB Homes in a compartment
• get_db_home — get a single DB Home by OCID
• list_db_systems — list DB systems in a compartment
• get_db_system — get a single DB system by OCID

How many IP addresses do I need for the Autonomous Recovery Service

 One of the most common questions that comes up is "How many IP addresses do I need to set aside for the Autonomous Recovery Service" or "How big does the CIDR block need to be for my Recovery Service subnet"?

In this blog post, I will explain how IPs are used by the service, but how many IP address you will need is hard to put an exact number on.

First below is a diagram showing how this works.

Recovery Service Subnet(s)

The first piece to understand is how the Autonomous Recovery Service uses the Subnet(s) that are registered.

First you might be wondering why I have the "(s)" on the end.  When you register a recovery service subnet there are two levels.

You register a name for "Recovery Service Subnet" and this is actually a group of subnets. You can register multiple subnets as eligible to be used for a "Recovery Service Subnets".

 The screenshot above is what you will see in OCI. 

When you register a Recovery Service subnet,

• You give it a name for the "Recovery Service subnet group" 
• You identify the VCN that this subnet is registered for. Each VCN will have it's own registered subnet group.
• You add one or more subnet within that VCN that can be used for endpoint IP address.

Any of these registered subnets can be used for Autonomous Recovery Service IP addresses.

Also subnets can be added, and removed within the group.

How many IP addresses for a Database backup?

I am going to start with a single database before I explain what happens when you have multiple databases using the service.  In order to support Oracle Database backups, the Autonomous Recovery Service uses endpoint IP addresses that map to a pair of ZDLRAs that store the backups as a service.  The pair of ZDLRAs provide an always available service.

For a single database below is what you would see for the endpoints that get created. In my example, you can see that there are 3 IP address per RA in the "Recovery Service Group".

Above, this shows the 6 private endpoint IP addresses that are created for the database backups being sent to two ZDLRAs (RA-018 and RA-020).  There are also FQDN names that are created for each each of the endpoints and you can see that the names map to the specific ZDLRAs that are storing the backups

NOTE: There are are also some 4 node ZDLRAs in some regions. In that case there will be 4 endpoint IP address for each ZDLRA in the pair, and a total of 8 IP addresses will be utilized.

How many IP addresses do I need for multiple databases?

This is where the answer is "It depends".  The simple example above shows you what happens for a single database. When you add another database it might not end up on the same "Recovery Service group". It is possible the new database backups could end up on another "Recovery Service group" needing additional IP addresses.

There are number of factors that affect how many "Recovery Service groups" are used when backing up multiple databases.

• Number of databases - If you have a large number of databases, this increases the chances that more backup locations will be used to spread out the backups across multiple groups.
• Size of the Database backups - if your backups are very large, the Recovery Service tries to balance larger database backups across more groups. 
• Number of groups in the region - Some regions contain more "recovery Service groups" than other regions.  If you are backing up in a larger region there is a higher chance that more groups will be utilized to support many databases.

The diagram I started with below shows you what happens with 3 databases that are storing their backups across two different Recovery Service groups.

The first database is sending it's backup to a Recovery Service Group containing two X 2 DB node  ZDLRAs and it is utilizing 6 IP addresses.

The second and third databases are using the same Recovery Recovery Group which consists of Two X 3 DB node ZDLRAs and they are using the same 8 IP addresses.

How to interpret this?

The recommendation for Recovery Service Subnets is to create a separate subnet that is a /24 CIDR block which will provide the ability to have 254 private endpoint IP addresses. This will allow for at least 31 different Recovery Service groups.

If you only have a few databases, then this may be too big for what you need, and you may be able to have a smaller CIDR block, or have multiple subnets with smaller CIDR blocks.

The recommendation of /24 CIDR blocks ensures you will not have any issues with enough IP address.

As you decrease the number of available IP addresses you increase the chances that you will not enough IP address to add another database to be backed up to the Autonomous Recovery Service.

What happens if I don't register enough free IPs?

Once a database is added is configured for backups, it will not affect the need for additional free IP addresses.  The only time you will have an issue with free IP addresses for the recovery service is when you add a new database to be backed up. If the onboarded process decides that the backups need to reside a new Recovery Service Group of ZDLRAs, and there are not enough free IP address you will receive an error when configuring backups. At that point you can add more subnets to the Recovery Service subnet group registered with the VCN.

Do I have to worry about space since databases are assigned to Recovery Service groups?

No.  The recovery service will automatically manage the underlying storage for the database backups and move backups from one group to another group if needed in order ensure there is enough space for backups. Because of this, you may find that the names of the ZDLRAs where the backups reside could change over time. This is one of the reasons why the service dynamically creates the TNSNAMES entry as needed. The FQDN used for backups of a database will change if the database is moved because of space constraints.

Summary

There is no set number of number of IP addresses that need to be registered with the recovery service and freely available to be assigned for backups.  It is dependent on the size of your environment, and number of IP addresses utilized could grow as your environment adds more databases to be backed up.

If you have a start with a smaller number of IP addresses, keep an eye on the number of available IP address in subnets registered with the recovery service to ensure you have room to grow.

Recovery Service failure checks

 When using the Autonomous Recovery Service there are some prerequisites that need be met. I have a checklist that goes through these requirements, and you can find that checklist here.

This blog post will help you perform some basic debugging and demonstrate what errors you will see if you miss some of the steps.

I want to point out that Billy Zou created a create post that will help you work through issues with Cross-region restore. Billy's post has some great information to use for debugging and you can find it here.

This post is broken into two possible places where you will have issues.

1. Unable to Submit request. This can be caused by
• Policy issues
• Limits issue
2. You submitted backup, but it failed to configure the Recovery Service. This can be caused by
• DNS issues with resolving FQDN used by Recovery Service
• Routing/port issues accessing the Recovery Service or Object Storage

Unable to submit Autonomous Recovery Service as a backup location

Policies for the tenancy

The first step is to ensure that you have configured policies for the recovery service.  The easiest way to do this is by utilizing Policy Builder.

NOTE: There is a policy that grants access to the "ADMIN" group. If your administrator group is a different group, you would 

Visible Issue

 If policies are not configured properly, you find that "Recovery Service" is greyed out as an option.

Limits for the Recovery Service

By default if you are not in a multi-cloud environment your paid tenancy will have a limit of

• 10 Database
• 10 TB of backups storage

If you are using Multi-cloud, and your database is in partner cloud, there is no default limits (defaulting to 0!), which means you have to apply for a limit increase!

This is the most common issue I see with multicloud.  You need to set the limit specifically for the multi-cloud subscription.

Visible Issue

 If limits  are not configured properly, you find that "Recovery Service" is greyed out as an option.

Below the choice for "Recovery service", you will see that there is a warning, telling you that you have exceeded your limits.