Zero Data Loss Autonomous Recovery Service FAQ

General

What is Oracle Database Zero Data Loss Autonomous Recovery Service?

Oracle Database Zero Data Loss Autonomous Recovery Service is a fully managed data protection solution designed to safeguard Oracle databases across multiple cloud platforms, including Oracle Cloud Infrastructure (OCI), Amazon AWS, Microsoft Azure, and Google Cloud. Purpose-built for Oracle AI Database protection and cyber resiliency, it protects database transactions in real time, continuously validates backup integrity, and provides fast database recovery without data loss.

Recovery Service delivers a uniquely robust, efficient, and cost-effective solution for protecting critical Oracle AI Database assets in the cloud.

What database versions are supported?

Recovery Service can be used to protect Oracle Database 19c and Oracle AI Database 26ai Standard and Enterprise Editions. Refer to the documentation for specific version and release details.

Is Recovery Service integrated with the Oracle Recovery Manager (RMAN) API?

Oracle RMAN is a foundational part of Recovery Service technology with integration extending well beyond that of the API. Purpose-built for Oracle AI Database protection and ransomware resiliency, Recovery Service is natively integrated with database technologies delivering predictably fast recovery to any point in time without data loss.

Oracle RMAN is used in coordination with the proven technology foundation of Oracle’s Zero Data Loss Recovery Appliance. Recovery Service adds end-to-end cloud automation for ease of use and cloud economics that make higher availability and resiliency available for any size organization or budget.

Can file system data or any non-Oracle databases be backed up to Recovery Service?

No, Recovery Service is purpose-built for Oracle AI Database protection and cyber resiliency.

How much does Recovery Service cost?

Cost is based entirely on how much storage is needed for your backups with pay-as-you-use consumption and no upfront costs. The base version, Oracle Database Autonomous Recovery Service, is the default option for automatic backups and is priced about the same as Oracle Cloud Infrastructure (OCI) Object Storage backups while offering far greater business value.

For about 30% more, Oracle Database Zero Data Loss Autonomous Recovery Service introduces real-time data protection, enabling you to recover to the point of your last committed transaction, greatly reducing business risk.

Which clouds and cloud regions offer Recovery Service?

Recovery Service is available in most OCI commercial regions and select AWS, Azure, and Google Cloud regions. It’s being actively rolled out to additional multicloud data centers.

Please refer to the current service availability list by cloud and region.

What is Cloud Protect?

Cloud Protect expands Recovery Service support to include Oracle databases running on any Linux x86–64 platform on-premises or in the cloud. Cloud Protect brings intelligent database protection and cyber resiliency along with all the cloud economic advantages to on-premises Oracle databases. It enables you to send backups to Autonomous Recovery Service or Zero Data Loss Autonomous Recovery Service located in any OCI region.

Availability

What resiliency and fault tolerance are built into the architecture?

Recovery Service runs on Oracle’s Zero Data Loss Recovery Appliance, an Oracle Engineered System that integrates software, compute, and storage resources and incorporates Oracle Maximum Availability Architecture (MAA) best practices with no single point of failure.

Deployed in a high-availability configuration, Recovery Service automatically replicates backups to another instance within the same cloud region at no additional cost. This built-in resiliency provides zero downtime maintenance; and the infrastructure is fully managed by Oracle Cloud engineers.

How does real-time data protection enhance ransomware resiliency?

Recovery Service is natively integrated with Oracle Data Guard redo transport technology to protect database transactions in real time, thereby reducing recovery point objectives (RPO) to less than a second. Without this, RPO would be at least 15 minutes, but typically hours or even a full day—the amount of time since your last backup.

With a single click, you can enable real-time data protection, making Recovery Service an alternative archived log destination for the protected database. As redo changes are generated in the database memory, they’re automatically sent to and validated on Recovery Service as received. When a database log switch occurs, Recovery Service automatically creates a compressed archived log backup and registers it in the recovery catalog.

What happens if real-time data protection is enabled and connectivity to Recovery Service is lost?

If the redo stream terminates unexpectedly, Recovery Service closes the incoming redo stream and creates a partial archived redo log file backup, thereby protecting transactions up to the last change received. When Recovery Service detects that the redo stream has restarted, it automatically retrieves all missing archived redo log files from the protected database to preserve the intended user-defined recovery window goal.

If redo logs are already on the Recovery Service, are incremental backups still needed?

Yes. Daily incremental backups make the recovery process faster and more efficient than restoring and applying days or weeks of archived log backups during recovery.

If real-time data protection is enabled, are archived log backups still needed?

No. Recovery Service protects database transactions as they occur, automatically creating archived log backups when a database log switch occurs. Since archived log backups already reside on the Recovery Service, it eliminates the need to perform and send periodic archived log backups to Recovery Service.

Security

What logical separation exists between production databases and backups?

Recovery Service is designed to be fault isolated from the production databases it protects. It operates within an Oracle-managed tenancy, utilizing private endpoint connectivity to the customer's tenancy. This architecture provides a logical air gap adding an extra security buffer; if a cyberattack compromises the production database, the Recovery Service remains unaffected.

How can Recovery Service minimize typical attack vectors and reduce the surface area of attack?

Recovery Service is purpose-built for Oracle AI Database, thereby reducing exposure to various distributed file systems and applications with differing security protocols. Communication between protected databases and Recovery Service is orchestrated by Oracle RMAN, which manages all data movement for backup and recovery operations.

Backups are accepted only from pre-enrolled databases. During the ingestion process, all backups are validated to confirm they are readable by Oracle RMAN before being stored on disk. This validation process rejects any files that do not meet the criteria, such as executable (.exe) files, which are common attack vectors.

What access controls and user separation of duties are available?

Recovery Service provides fine grain access controls over user privileges and tasks, enabling organizations to address a wide range of security requirements. You can easily create Oracle Cloud Infrastructure user accounts and groups to manage Recovery Service resources with predefined templates and customized policies.

Refer to the Recovery Service documentation on creating groups and users along with permissions needed when running Recovery Service in Oracle’s public cloud data centers or multicloud policy templates.

Does Recovery Service support backup immutability?

Yes. Recovery Service protection policies enable you to set a strict retention-locked period in which deletion or shortening the retention period is prohibited.

What is the storage consumption impact of backing up encrypted databases?

Since Recovery Service is integrated with Oracle Transparent Data Encryption (TDE) formats, the storage impact is negligible. Recovery Service compresses TDE-encrypted databases during backup for faster more, space-efficient data protection. Backup compression, coupled with an incremental forever strategy maximizes efficiency, keeps backup storage consumption to a minimum, thereby lowering overall costs.

With traditional backup solutions, one could expect backup storage consumption to increase since encrypted data typically cannot be compressed or deduplicated. Recovery Service effectively eliminates this backup storage tax that comes with end-to-end data security encrypting at its source—all within the database.

Are backup encryption keys stored on Recovery Service?

No. Encryption keys for protected databases secured with Oracle Transparent Data Encryption are managed by the protected database stored in an Oracle Wallet, Oracle Key Vault, Azure Key Vault, or other integrated key management system.

How is backup and restore data securely sent over the network?

Recovery Service uses a designated private subnet for backup and recovery operations to provide network isolation and access control. Each virtual cloud network (VCN) should have at least one private subnet configured for backups, which can then be registered with Recovery Service enabling connectivity between the database and service.

OCI policies can be assigned for access control, such as permitting Recovery Service to access databases only in a chosen VCN. Refer to Recovery Service documentation for more details on subnet management.

Is backup encryption required for databases running on-premises using Cloud Protect?

Yes. Cloud Protect automatically compresses and encrypts backups. RMAN backup encryption and compression is included in your Cloud Protect subscription at no additional cost—licenses for Oracle Advanced Compression and Advanced Security Options are not required.

Operational management

How do protected databases connect and communicate with Recovery Service?

Protected databases use the Recovery Service backup module, an Oracle SBT library that Oracle RMAN uses to transfer backup data over the network to the service. Since it’s embedded in database software, no additional components need to be installed.

For databases running in OCI or multicloud database services, simply select Autonomous Recovery Service (recommended) as your destination when setting up automatic backups. Optionally, you can enable real-time data protection to use Zero Data Loss Autonomous Recovery Service.

When configuring Cloud Protect, specify which cloud region and virtual cloud network (VCN) in your tenancy to use for backing up to Recovery Service. Once these settings have been defined, your backup environment will be automatically configured for an incremental backup forever strategy after the initial full. You’ll then be prompted for scheduling settings and if you’d like to enable real-time data protection (Zero Data Loss Cloud Protect).

Is an Oracle Recovery Manager catalog required?

No. Recovery Service has a fully managed, built-in recovery catalog that provides all the advantages of an Oracle RMAN catalog. It also handles the metadata for Recovery Service policies, settings, and operations.

Does the backup location need to be specified when initiating a restore operation?

No. Recovery Service keeps track of backups, replicas, and archival copies along with retention associated for each and will automatically initiate restore from the optimal source. For example, if a backup no longer resides on Recovery Service, but an archival backup copy is available, it will be automatically restored without user intervention.

In multicloud environments, can backups to Recovery Service be stored in the same cloud?

Yes. When configuring Recovery Service as your automatic backup destination, you have the option to select that backups are stored on Recovery Service in the same cloud where the production database runs, for example, OCI, AWS, Azure, or Google Cloud. If this option is not selected, backups will be stored on Recovery Service located in OCI data centers.

On-demand long-term retention copies are stored in Oracle’s public cloud data centers on Oracle Cloud Infrastructure (OCI) Object Storage Infrequent Access tier. In multicloud environments, this is conceptually similar to how tape backups were sent to offsite storage for the duration of their retention periods.

How can administrators centrally manage their backup strategy for all databases?

The OCI Console provides a unified interface to centralize your backup strategy for all Oracle Cloud databases in your tenancy. You can use the Database Backups page to configure Recovery Service resources, monitor backups of protected databases, and analyze your backup storage utilization for individual databases.

Can automatic alerts be generated to notify administrators of pressing issues?

Yes. Use the Oracle Cloud Infrastructure Monitoring service alarms feature to monitor your protected database resources and notify you when metrics meet alarm-specified triggers.

From each metric displayed on the protected database details page, you can set an alarm and be notified when a user-defined condition is met. For example, you can create an alarm to notify you when the space used for the recovery window is more than 70% or when the protected database health status changes to 1 (warning).

Can backups managed by the service be used to create database clones or instantiate a Data Guard standby?

Yes. The database administrator can easily select which virtual full backup should be used for the clone or to instantiate a Data Guard standby.

How do protected databases connect and communicate with Recovery Service?

Protected databases use the Recovery Service backup module, an Oracle SBT library that Oracle RMAN uses to transfer backup data over the network to the service. Since it’s embedded in database software, no additional components need to be installed.

For databases running in OCI or multicloud database services, simply select Autonomous Recovery Service (recommended) as your destination when setting up automatic backups. Optionally, you can enable real-time data protection to use Zero Data Loss Autonomous Recovery Service.

When configuring Cloud Protect, specify which cloud region and virtual cloud network (VCN) in your tenancy to use for backing up to Recovery Service. Once these setting have been defined, your backup environment will be automatically configured for an incremental backup forever strategy after the initial full. You’ll then be prompted for scheduling settings and if you’d like to enable real-time data protection (Zero Data Loss Cloud Protect).

In multicloud environments, can backups to Recovery Service be stored in the same cloud?

Yes. When configuring Recovery Service as your automatic backup destination, you have the option to select that backups are stored on Recovery Service in the same cloud where the production database runs, for example, OCI, AWS, Azure, or Google Cloud. If this option is not selected, backups will be stored on Recovery Service located in OCI data centers.

On-demand long-term retention copies are stored in Oracle’s public cloud data centers on Oracle Cloud Infrastructure (OCI) Object Storage Infrequent Access tier. In multicloud environments, this is conceptually similar to how tape backups were sent to offsite storage for the duration of their retention periods.

Can we use our existing OCI cloud tenancy when setting up Cloud Protect?

Yes. You’ll need an OCI cloud tenancy (account) to backup on-premises Oracle databases to Recovery Service in Oracle’s public cloud and you may use an existing one or easily set one up.