Cloud Protect is a new offering announced at AI World 2025. Cloud Protect allows you to leverage the Oracle Database Zero Data Loss Autonomous Recovery Service for your on-premises Linux x64 databases. Cloud Protect even allows you to enable real-time redo.

You can find a great blog post by Kelly Smith announcing it here, and you can find the detailed documentation here.

I've been testing it out for the past week and I wanted to share everything I learned about using it.

First, there are a few things to understands about Cloud Protect Version 1.

You can only restore the database back to the original host/cluster you configured backups from. All nodes in a RAC cluster can be used for restoration.
Cloud Protect can only be used from non-ExaCC on-premises databases.
You cannot use a dual point-in-time backup strategy. Cloud Protect must be your primary backup location.

Prerequisites

The prerequisites for Cloud Protect are very similar to the prerequisites for the recovery service. You can find a detailed checklist here.

There are some items that you should take a closer look at for Cloud protect

Encryption Keys (TDE is not required) - In order to utilize Cloud Protect, you must have an encryption key set for the CDB and any PDBs. The key may be in a wallet, or in an external keystore like OKV. This key is used to RMAN encrypt the backups, and this functionality does not require the ASO license (note - it only includes RMAN encryption. TDE would still require an ASO license).

Recovery Service Subnet - In order for the RMAN client to connect to the catalog, the client must be able to communicate with endpoints in the Recovery Service subnet. Unlike recovery service, where the endpoints are typically created within the same VCN, or even within the same subnet, this is not the case with Cloud Protect. You must ensure that there is a network path between the protected DB hosts and the Recovery Service subnet.

DNS resolvable endpoints from OCI - In some cases environments may be set up that cannot resolve FQDN names that only reside within the customers tenancy in OCI. In order for the Protected Database to communicate with Cloud Protect, it uses DNS entry that resolve in OCI, and DNS must be configured to include this additional resolution.

Open Ports from protected database to OCI - Ports 2484 and 8005 must be open to allow traffic to the Cloud Protect endpoints. Since protected databases reside outside of the VCN used for Cloud Protect, you must make sure the protected database can connect across these two ports.

Architecture

The architecture diagram below shows how backups are passed to Cloud Protect.

Additional Prerequisites

There are a few additional prerequisites for Cloud Protect

Oracle Cloud Account - To send backups to Cloud Protect you need to configure an account with external authentication. I would recommend creating a new account for backups. This ensures the account isn't tied to a specific individual DBA account. Along with a specific account, you should create a new group allowing you to have possibly multiple accounts for administering backups. Finally, this group should be granted ability to manage recovery-service-family

Allow group {Cloud Protect Group} to manage recovery-service-family in tenancy

Create a new API key for this generic Cloud protect user in OCI. This can be done in the console by selecting the user under Identity & Security -> {User} -> API keys. You can have a new public private key generated, and you then download the key files. Once the key is added you are provided a popup giving you the values for the .oci/config file on the protected DB host.

Configure OCI authentication. From the previous step store the config file on the DB host in ~/.oci/config. Update the config file to point to the private key stored in a protected file, and store the private key file locally. This should be done on each node you plan on managing Cloud Protect.

Enable RMAN encryption - In RMAN you must make sure that "configure encryption for database ON" is set.

Additional Information

Unlike configuring recovery service, you must provide a few pieces of additional information when configuring Cloud Protect.

Compartment OCID - You need to identify the compartment where you want the backups to be stored. In the console you need to go to Identity & Security -> Compartments and chose the compartment where you want to store the backups. Copy the OCID from here and it should be in the format ocid1.compartment.oc1..{identifier}
Recovery Service Subnet OCID - By this point you should have a recovery service subnet registered. In the console you need to go to Oracle AI Database -> Database Backups . Select the compartment where the Recovery Service Subnet resides. Select the recovery service subnet from the left hand side. Copy the OCID from here and it should be in the format ocid1.recoveryservicesubnet.oc1..{identifier}
Protection Policy - While in the Database Backups section identify the Protection policy you want to use and save it. It is case sensitive when entered later.

Architecture below shows how backups are passed to Cloud Protect.

Set up Cloud Protect (SQLcl)

Follow the instructions in the documentation you can find here.

These steps will

Install SQLcl
Enable the scheduler used by SQLcl
Start the scheduler used by SQLcl
Check the status of the scheduler used by SQLcl

Configure DB backups

The easiest way to add databases is individually to ensure the process is working correctly. There is a process to add all databases, but I recommended this method until you are familiar with the process.

1) Add sysbackup user

Configure your environment to the database you want to onboard to Cloud Protect

". oraenv". Ensure ORACLE_BASE, ORACLE_SID and ORACLE_HOME are all set correctly.

Log into sql

>sql /nolog

Once logged in add the sysbackup user

SQL> rcv add sysbackup_user -db_unique_name <db unique name>

Below is the output I see after executing this.

  
SQL> rcv add sysbackup_user -db_unique_name cloudp_8h5_iad
2025-10-24 14:05:50: Log file: /u01/app/oracle/rcv/log/add_sysbackup_user.20251024.140550.log
2025-10-24 14:05:52: Successfully created sysbackup user. You can login to the database as the sysbackup user by running "sql -name cloudp_8h5_iad_rcv_conn".
2025-10-24 14:05:52: rcv add sysbackup_user completed successfully
SQL> exit

2) Login using the credentials created in step #1

>sql -name <db unique name>_rcv_con

3) Add the database passing the compartment OCID, Recovery Service Subnet OCID and the name of the protection policy

SQL> rcv add database -compartment_id ocid1.compartment.oc1..{identifier} -recovery_service_subnets ocid1.recoveryservicesubnet.oc1.iad.{identifier} -protection_policy_name Bronze

The output is below

2025-10-27 14:19:29: Log file: /u01/app/oracle/rcv/dbs/cloudp_8h5_iad/log/add_database.20251027.141929.log
2025-10-27 14:19:29: Start - step 1 of 9
2025-10-27 14:19:29: Running prechecks
2025-10-27 14:19:29: Database Version Check
2025-10-27 14:19:29:    Status:      PASS
2025-10-27 14:19:29: --------------------------------------------------
2025-10-27 14:19:29: Encryption Key Check
2025-10-27 14:19:29:    Status:      PASS
2025-10-27 14:19:29: --------------------------------------------------
2025-10-27 14:19:29: Archive Log Mode Check
2025-10-27 14:19:29:    Status:      PASS
2025-10-27 14:19:29: --------------------------------------------------
2025-10-27 14:19:29: Database Status Check
2025-10-27 14:19:29:    Status:      PASS
2025-10-27 14:19:29: --------------------------------------------------
2025-10-27 14:19:29: RMAN Encryption check
2025-10-27 14:19:30:    Status:      PASS
2025-10-27 14:19:30: --------------------------------------------------
2025-10-27 14:19:30: SUCCESS
2025-10-27 14:19:30: --------------------------------------------------
2025-10-27 14:19:30: Start - step 2 of 9
2025-10-27 14:19:30: Initializing metadata directory
2025-10-27 14:19:30: SUCCESS
2025-10-27 14:19:30: --------------------------------------------------
2025-10-27 14:19:30: Start - step 3 of 9
2025-10-27 14:19:30: Onboarding database to Recovery Service
2025-10-27 14:19:36: Verifying lifecycle state
2025-10-27 14:20:17: SUCCESS
2025-10-27 14:20:17: --------------------------------------------------
2025-10-27 14:20:17: Start - step 4 of 9
2025-10-27 14:20:17: Updating client configuration
2025-10-27 14:20:17: SUCCESS
2025-10-27 14:20:17: --------------------------------------------------
2025-10-27 14:20:17: Start - step 5 of 9
2025-10-27 14:20:17: Registering database with recovery catalog
2025-10-27 14:20:28: SUCCESS
2025-10-27 14:20:28: --------------------------------------------------
2025-10-27 14:20:28: Start - step 6 of 9
2025-10-27 14:20:28: Configuring RMAN
2025-10-27 14:20:28: SUCCESS
2025-10-27 14:20:28: --------------------------------------------------
2025-10-27 14:20:28: Start - step 7 of 9
2025-10-27 14:20:28: Backing up control file
2025-10-27 14:20:40: SUCCESS
2025-10-27 14:20:40: --------------------------------------------------
2025-10-27 14:20:40: Start - step 8 of 9
2025-10-27 14:20:40: Saving metadata
2025-10-27 14:20:40: SKIPPED
2025-10-27 14:20:40: --------------------------------------------------
2025-10-27 14:20:40: Start - step 9 of 9
2025-10-27 14:20:40: Scheduling tasks
2025-10-27 14:20:40: SUCCESS
2025-10-27 14:20:40: --------------------------------------------------
2025-10-27 14:20:40: rcv add database completed successfully

Show DB configuration

Once you configure the database, archive log sweeps and daily L1 backups will automatically be scheduled.

You would log in using the credentials, and I recommend creating an alias.

>sql -name <db unique name>_rcv_con

SQL> rcv show database

2025-10-28 21:33:23: Log file: /u01/app/oracle/rcv/dbs/cloudp_8h5_iad/log/show_database.20251028.213323.log
2025-10-28 21:33:24: DB Unique Name:    cloudp_8h5_iad
2025-10-28 21:33:24: Display Name:      cloudp_8h5_iad
2025-10-28 21:33:24: OCID:              ocid1.recoveryserviceprotecteddatabase.oc1.iad.amaaaaaauiqzkiaajaf6rsexjfvnlbhzkmo2hxldvemmqluu5cyutie2nqcq
2025-10-28 21:33:24: Compartment ID:    ocid1.compartment.oc1..aaaaaaaanqbquh2bwju4igabu5g7clir2xuiijael2fwcpqyvzzb4ykd3tyq
2025-10-28 21:33:24: Status:            Active
2025-10-28 21:33:24: VPC User:          JJQVZI2SKTBW6JVDSVY9RMJH4XZNSF
2025-10-28 21:33:24: Real-time Redo:    false
2025-10-28 21:33:24: Protection Policy:
2025-10-28 21:33:24:    Name:               Bronze
2025-10-28 21:33:24:    ID:                 ocid1.recoveryservicepolicy.region1..aaaaaaaam22xkw32t524xvst7dbxz4qsxtwetmfnnxfsgslbq664vya5jbkq
2025-10-28 21:33:24:    Retention Period:  14 days
2025-10-28 21:33:24: Health:            Protected
2025-10-28 21:33:24: Health Details:    Protected Database is Healthy. Last updated on Tue Oct 28 21:31:30 UTC 2025
2025-10-28 21:33:24: Metrics:
2025-10-28 21:33:24:    Minimum Recovery Time:     0.0 days
2025-10-28 21:33:24:    Unprotected Window:        3240.0 seconds
2025-10-28 21:33:24:    Retention Period:          14.0 days
2025-10-28 21:33:24: rcv show database completed successfully

This should give you a good primer for Cloud Protect

Bryan's Oracle Blog

Tuesday, October 28, 2025

Configuring Cloud Protect