Hybrid Backup Strategies with Oracle Autonomous Recovery Service (Cloud Protect)

This article written by Johannes Michler and Christof König was originally published within #38 edition of ORAWORLD e-Magazine.

A key component of any IT strategy focused on availability and resiliency is a robust backup architecture that ensures recoverability across different failure scenarios. Oracle Autonomous Recovery Service enables consistent, secure, and automated hybrid backups for both on‑premises and cloud databases.

This article outlines why hybrid  backups (a combination of cloud and on-premises) are an attractive alternative to traditional backup approaches and how they can be configured.

Outages caused by cyberattacks, hardware failures or operational mistakes are unavoidable. At the center of every recovery plan are two key metrics: the Recovery Point Objective (RPO), which defines the acceptable data loss window, and the Recovery Time Objective (RTO), which determines how long a system can remain offline during restoration.

It is also essential to decide what types of failures need to be covered. Hybrid backups can significantly enhance backup strategies when local datacenter outages must be mitigated. At the same time, cloud backups offer scalability and options for immutability, both especially relevant in ransomware scenarios.

Oracle’s Maximum Availability Architecture outlines a range of mechanisms designed to ensure high availability, with backups forming one of its essential components.

Oracle Autonomous Recovery Service is a fully managed cloud service for Oracle Database backup, recovery and optional zero data loss protection and immutable backups. It supports databases running on premises, in Oracle Cloud and across multicloud deployments including Azure, Google Cloud and AWS.

The service uses an incremental forever design that maintains small individual backup sets. Behind the scenes, a virtual full backup is continuously assembled, which enables rapid recovery without the overhead of repeated full backups.

The service operates within a private subnet inside Oracle Cloud Infrastructure and is accessible exclusively through a VPN connection. For on premises environments, the Fleet Agent manages communication between the database and the Recovery Service.

Backups are stored in Object Storage, although in multicloud environments, storage services from the respective cloud provider can be used.

All backups rely on Transparent Data Encryption (TDE), which does not require additional licensing. Because Recovery Service DOES NOT store the corresponding encryption keys, the TDE wallet must be backed up separately to ensure recoverability.

Retention periods between 14 and 95 days are defined through policies, while long term retention of up to ten years is currently available only within cloud environments.

Recovery operations can target both on premises systems and OCI resources, allowing organizations to fall back to cloud infrastructure without maintaining dedicated on site restore hardware.

Several preparations are necessary before a database can be registered with the service:

• OCI Preparations: A private subnet must be created and associated with the Recovery Service. An API key is required for database communication, and it is advisable to use a dedicated service user for this purpose. If no site to site VPN is in place, it must be configured beforehand.

• DB Preparations: SQLcl must be installed to support communication with the Recovery Service. A TDE wallet needs to be set up, and RMAN encryption must be enabled. A secure backup of the TDE wallet is essential, as recovery is not possible without it.

Once the preparations are complete, the database is connected to the service:

• Configuring SQLcl: Authentication is configured first.

rcv configure authentication -method api_key -oci_config <API configuration file location>

• Registering the database: The database is then registered using SQLcl: A configuration file can be generated first. After it has been reviewed, the database is then fully registered.

rcv add database -auto_discover -generate_config_only -compartment_id <COMPARTMENT_OCID> -recovery_service_subnets <SUBNET_OCID>
rcv add database -config /u01/oracle/rcv/add_database.574634.json

• Optional: Enabling Zero Data Loss: In addition, the Zero Data Loss option is available. In this mode, the redo logs are sent to the Recovery Service in order to reduce potential data loss to nearly zero.

rvc add realtime_redo

Once registered, Autonomous Recovery Service automatically schedules and executes all backup operations. Backup management is handled centrally and independent of the source database, which improves consistency and transparency. The sheduling and execution is performed on the source database.

With real time redo shipping, redo data is transferred almost immediately, allowing extremely low RPO values comparable to those of a physical standby database but without the associated infrastructure requirements.

Recoveries rely on standard RMAN procedures supported by environment files generated by SQLcl. Restores can be executed on premises or in OCI without the need for dedicated restoration hardware. Temporary compute instances can be provisioned in the cloud to speed up recovery testing or to support emergency operations.

At present, it is not possible to restore directly to a managed Oracle Cloud database service. Instead, a compute instance must be used, which mirrors the workflow of an on premises restore.

Based on our experience, the following best practices and recommendations can be derived:

• TDE‑Wallet

The TDE wallet must be securely stored and backed up separately.

• Network Bandwidth

Ensure sufficient bandwidth for the incremental forever backup flow so that backup windows remain short.

• Retention Policies

Define standardized retention policies and avoid excessive exceptions.

• Immutable Protection

Enable immutability to protect against data manipulation or ransomware. Carefully plan IAM roles and privileges.

• Test‑Restores

The restore strategy must be tested for real world emergency scenarios, which makes regular restore tests essential. Both on premises and cloud environments should be considered as target systems during these tests.

• Consider Limitations

The prerequisites and limitations must be taken into account. Particular attention should be paid to the VPN connection, as it will also be required on premises in an emergency. It should also be noted that, at present, no cross region backup replication takes place. In a hybrid backup scenario (on premises → OCI), this can be disregarded. However, for cloud only backups, it must be considered.

Oracle Autonomous Recovery Service represents a strong enhancement to modern backup strategies. It requires relatively little initial setup while providing a geographically separate backup target, eliminating the need for a second physical location. In a disaster scenario, OCI compute resources can serve as temporary replacement hardware, streamlining recovery processes.

Immutable storage further strengthens the integrity of stored backups. Because the service is flexible and supports a wide range of Oracle Database environments, it offers a highly practical, cloud ready approach to hybrid data protection.