This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software, software documentation, data (as defined in the Federal Acquisition Regulation), or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed, or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software," "commercial computer software documentation," or "limited rights data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed, or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract. The terms governing the U.S. Government's use of Oracle cloud services are defined by the applicable contract for such services. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle®, Java, MySQL, and NetSuite are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Inside are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Epyc, and the AMD logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.
Backup and Recovery Ecosystem
Notes
Database Backup Administrators (DBA) are responsible to devise, implement, and manage a backup and recovery strategy to avoid data loss and to reconstruct a database in case of data loss. Oracle's Database Backup and Recovery solutions offer an integrated range of backup and recovery options, both on-premises and on Oracle Cloud, which help you to adopt a comprehensive approach to data protection.
Oracle's backup and recovery ecosystem is designed to support a secure backup strategy which includes short-term and long-term storage options, simplified backup administration, enhanced data protection, and sub-second recoverability in case of data loss. These are the critical components that constitute Oracle's backup and recovery ecosystem.
Oracle Recovery Manager (RMAN): Oracle's built-in backup and recovery engine for Oracle AI Databases. RMAN provides performance efficient and dependableprotection. RMAN is fully integrated with the Oracle AI Database to perform a range of backup and recovery activities, including maintaining an RMAN repository of historical data about backups. As a Database Backup Administrator (DBA), you can use RMAN to connect to a target database, create and send backups directly to storage tape drives, hard disk drives, third-party storage devices, Oracle Cloud Infrastructure (OCI) Object Storage and the Zero Data Loss Recovery Appliance (RA). You can access RMAN through the command line or through Oracle Enterprise Manager. Using RMAN and RMAN backups, you can easily duplicate a target database and also migrate a database from a source platform to a destination platform. RMAN maintains a repository of metadata about its operations. This metadata is always stored in the control file of a target database. You can also store the RMAN operational metadata in a separate database called the recovery catalog. The recovery catalog is a separate database schema used to record RMAN activity against one or more target databases. A recovery catalog preserves RMAN repository metadata if the control file is lost, making it much easier to restore and recover following the loss of the control file. RMAN uses the Fast Recovery Area (FRA) to store recovery-related files such as control file and online redo log copies, archived redo logs, flashback logs, and RMAN backups. The fast recovery area is an optional disk location of your choice and has a upper limit for storage space. Using retention policies, the database manages the storage space required for backups, archived redo logs, and other recovery-related files within the allocated space. Files that are no longer needed are eligible for deletion when RMAN must reclaim space for new files.
Oracle Secure Backup (OSB): A network based backup management application that can back up both databases and file system data to tape, disk, and cloud storage devices. Oracle Secure Backup serves as a system backup to tape (SBT) interface (media management layer) required for RMAN to send encrypted backups directly to tape storage. File-system data can be defined as the collection of files and file management structures on physical or logical storage. Oracle Secure Backup can initiate the backup for any type of file in a file system. You can schedule file system backups to occur at specified intervals. The Exadata Database Service on Cloud@Customer system can backup its file system data to Oracle Secure Backup.
Zero Data Loss Recovery Appliance (Recovery Appliance): Oracle's Engineered System provides data protection for all Oracle AI Databases in the enterprise. Integrated with RMAN and Oracle Enterprise Manager Cloud Control, Recovery Appliance (RA) provides a single backup repository for multiple databases. A protected database is a client database whose backups are managed by the Recovery Appliance. The Recovery Appliance Backup Module is an Oracle-supplied system backup to tape (SBT) library that functions as a media management library. RMAN uses the Recovery Appliance Backup Module to transfer backup data over the network to the Recovery Appliance. The Recovery Appliance metadata database is the Oracle database that runs within the Recovery Appliance. The RA metadata database stores configuration data such as definitions, protection policy definitions, and client database definitions. Exadata Database Service on Cloud@Customer has the ability to directly back up to Recovery Appliance.
Oracle Cloud Infrastructure Object Storage: A cost-effective, secure, offsite storage service. This service also enables you to migrate your on-premises databases to the Oracle Cloud Infrastructure (OCI) Object Storage for short term and long term backup storage. RMAN and the Recovery Appliance use the Oracle Database Backup Cloud module to backup on-premises databases to Object Storage (buckets). Oracle Cloud Databases use the OCI-managed automatic backups feature to send backups to the OCI Object Storage (buckets). Oracle Secure Backup uses Oracle Secure Backup cloud storage devices to backup and restore data to and from Object Storage. In OCI Object Storage,encryption is on by default so that the data stored in Object Storage is always encrypted. To migrate an on-premises database to Oracle Cloud, you can use RMAN and the Backup Cloud module to first save a backup to Object Storage and then instantiate the backup as a new Oracle Cloud database.
Autonomous Recovery Service: An Oracle Cloud subscription service for protecting Oracle Cloud Databases. Recovery Service is a fully managed service based on Oracle's Zero Data Loss Recovery Appliance technology. Recovery Service delivers enhanced data protection capabilities for Oracle Database services running on OCI. Recovery Service helps organizations meet the business-critical needs to reduce ransomware risk, financial requirements for improved operational efficiency, and user expectations for cloud service simplicity. In the first release, Recovery Service supports data protection capabilities for the Oracle Database Service on Dedicated Infrastructure service(ExaDB-D) and the Oracle Base Database service. Recovery Service processes backups, provides automated recovery validation, end-to-end encryption, and policy-driven backup retention. The continuous transfer of redo logs from a protected database to Recovery Service is called Real-time data protection. Recovery Service offers real-time data protection so that you can minimize the possibility of data loss and enhance database protection. For Oracle Cloud Infrastructure databases, such as ExaDB-D and Base Database, the OCI-managed Automatic Backups feature is the preferred method to back up and recover databases. You can use the OCI Console to enable the automatic backups feature and configure Recovery Service as the backup destination.
Backup and Recovery Components and Strategy Reference
Notes
Key Structural Components for Data Recovery
It is important to understand Oracle database structural components that are essential for data recovery.
System Global Area (SGA): The SGA is a shared memory structure that contains data and control information for a given database instance. The SGA contains separate buffer areas, such as the redo log buffer.
Redo Logs: In an Oracle Database, redo logs are the crucial structure for data recovery in case of a failure. A redo log consists of a minimum of two or more preallocated files that maintain logs of database transactions, as they occur, after a backup. Each redo log file is filled with redo records. Redo log entries are generated in the redo log buffer of the SGA. The log writer process (LGWR) is an Oracle background process that is responsible for writing the redo log buffer into redo log files. The database requires that each redo log contains a minimum of two redo log files to guarantee that one is always available for writing while the other is being archived (if the Oracle Database is running in the ARCHIVELOG mode). The LGWR process writes to redo log files in a circular fashion. When the current redo log file is full, LGWR begins writing to the next available redo log file.
Archived Redo Logs: When you cannot afford to lose data, Oracle recommends that you run your Oracle Database instance in the ARCHIVELOG mode. The ARCHIVELOG mode enables the archiving of filled redo logs. When a database is mounted, run the ALTER DATABASE ARCHIVELOG statement to enable the archiving of filled redo log files. You can choose to archive redo logs to more than one chosen destination. For example, you can archive filled redo logs to a local disk, an Oracle Automatic Storage Management (Oracle ASM) disk group, and the fast recovery area (FRA). Define the LOG_ARCHIVE_DEST_n initialization parameter to specify more than one destination to archive the filled redo logs. The database starts multiple archive processes, as needed, to ensure that the archiving of filled redo logs does not fall behind. A copy of each filled redo log file is written to each destination. In the event of a database failure, you can first restore a full database backup and then use the archived redo log files to recover a database to a recent committed transaction that occurred before a specified point in time.
Backup Concepts
Here are some key terms and concepts that concern the backup and recovery scenario for your Oracle Databases.
Recovery Point Objective (RPO): The point in time (in the past) to which you can recover lost data. RPO defines the data-loss tolerance of a business process or an organization. The RPO is often measured in terms of time, for example, five hours or two days worth of data loss.
Recovery Time Objective (RTO): The point in time (in future) at which you will restore your Oracle Database after its failure. RTO predicts the estimated period for database recovery.
Backup Window Time: The scheduled time taken for Oracle Database backups to begin and complete.
Backup Types: Full backup, incremental level 0 (L0) backup, incremental level 1 (L1) backup, and archived redo log backup.
Full Backup: A full backup includes all the allocated data blocks in a database. When you have connected RMAN to a target database, run the BACKUP DATABASE command to create a full backup.
Incremental Level 0 (L0) Backup: An L0 backup forms the base of an incremental backup strategy. An L0 backup also includes all the allocated blocks containing data. The only difference between an incremental L0 backup and a full backup is that a full backup is never included in an incremental strategy. When you have connected RMAN to a target database, run the BACKUP INCREMENTAL LEVEL 0 DATABASE command to create an L0 backup.
Incremental Level 1 (L1) Backup: An incremental L1 backup contains only the changed data blocks since the last incremental L0 or L1 backup was taken. L1 backups are always differential by default. A differential backup includes only the blocks which changed since the most recent L0 or L1 backup was taken. For example, assume that an L0 backup was taken on Sunday. On Monday, the L1 backup will include only the data that changed after the L0 backup was taken. Tuesday's L1 backup will contain only the changed data since Monday's L1 backup. When you have connected RMAN to a target database, run the BACKUP INCREMENTAL LEVEL 1 DATABASE command to create an incremental L1 backup.
Archive Redo Log Backups: In this approach, the database archive redo logs are backed up, typically on an hourly basis, so that the database can be recovered to a specified point in time in the event of a failure. When you have connected RMAN to a target database, run the BACKUP ARCHIVELOG command to backup the archived redo log files.
RMAN Backup Strategy to Recovery a Database After a Failure
You use Recovery Manager (RMAN), an Oracle Database client, to perform backup and recovery operations for your Oracle Databases.
4. Weekly Full, Daily Incremental and Hourly Archived Redo Log Backups: In this strategy, an incremental L0 backup is taken once a week. The subsequent incremental L1 backups can be taken on a daily or an hourly basis. Incremental L1 backups require lesser storage space and have shorter backup windows.
Consider an Oracle Database that is backed up (L0) weekly on Sundays at 11:00 PM. The daily incremental L1 backups are taken at noon everyday starting from Monday to Saturday. Monday's incremental L1 backup will contain all the changes that occurred in the database since Sunday's incremental L0 backup. However, Tuesday's incremental L1 backup will contain only the changed data since Monday's incremental L1 backup. This daily incremental L1 backup trend continues until the next weekly incremental L0 backup is taken. In addition, an hourly archived redo log backup is taken to ensure that the archived redo log files are backed up.
If a database failure occurs, you use RMAN to restore the database using the most recent incremental L0 backup, and recover the database by applying the incremental L1 backups and the most recent archived redo log backup. When RMAN is connected to a target database, run the RESTORE command to restore the data files from a backup. Run the RECOVERcommand to automatically restore and apply both incremental backups and archived redo logs.
Consider that a disk failure occurs at 3 PM, on Friday. You begin by restoring the L0 backup taken on Sunday, next apply the incremental L1 backups sequentially in the order of Monday through Friday, and finally apply the archive redo logs from the most recent archive redo log backup (taken at 2:45 PM on Friday, minutes before the crash). This ensures that you can recover the database with a recovery point objective that guarantees that you can recover all the committed transactions with minimal data loss and shorter recovery time.
Note: While recovering a database from failure, RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than applying redo logs.
5. In the absence of incremental L1 backups, restoring a database requires a very long recovery time because after you restore the full backup you must sequentially apply a long-chain of redo logs to recover the database to a specified point in time.
The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy.
Oracle Recovery Manager (RMAN) Client: The client application that manages backup and recovery operations for a target database. The RMAN client can use Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net. An RMAN channel represents one stream of data to a device, and corresponds to one database server session. During a backup or restore operation, the channel reads data from the input device, processes it, and writes it to the output device. The RMAN client directs database server sessions to perform all backup and recovery tasks. What constitutes a session depends on the operating system. For example, on Linux, a server session corresponds to a server process. On Windows, a server session corresponds to a thread within the database service. The RMAN client itself does not perform backup, restore, or recovery operations. Most RMAN commands are run by channels, which must be either configured to persist across RMAN sessions, or manually allocated in each RMAN session.
Target Database: A database containing the control files, data files, and optional archived redo logs that RMAN backs up or restores. RMAN uses the target database control file to gather metadata about the target database and to store information about its own operations. The work of backup and recovery is performed by server sessions running on the target database.
Control File: The RMAN repository is a collection of metadata about the target databases that use RMAN for backup, recovery, and maintenance. RMAN always stores its metadata in the control file. The version of this metadata in the control file is the authoritative record of RMAN backups of a database. Therefore, an important part of your backup strategy is to protect the control file.
Recovery Catalog Database: A database schema used by RMAN to store the metadata about its backup and recovery operations. A recovery catalog is a separate dedicated database and can be used to store the RMAN metadata for multiple target databases. A recovery catalog is optional because RMAN stores its metadata in the control file of each target database. However, a recovery catalog is required when you use RMAN in a Data Guard environment. The process of enrolling of a database in a recovery catalog for RMAN use is called registration. The recommended practice is to register every target database in your environment in a single recovery catalog. The recovery catalog contains metadata about RMAN operations for each registered target database. When RMAN is connected to a recovery catalog, RMAN obtains its metadata exclusively from the catalog. A user, within the recovery catalog database, owns the metadata tables maintained by RMAN. For RMAN operations such as backup, restore, and crosscheck, RMAN always first updates the control file and then propagates the metadata to the recovery catalog. This flow of metadata from the mounted control file to the recovery catalog, which is known as recovery catalog resynchronization or resync operation, ensures that the metadata that RMAN obtains from the control file is current.The recovery catalog database is a database like any other, and is also a key part of your backup and recovery strategy. To avoid losing metadata from disk failures that may destroy the recovery catalog database, You can use RMAN to back up the recovery catalog with the same frequency that you back up a target database. The repository for RMAN is the control file in the catalog database. Using the control file auto backup feature, you can ensure that the recovery catalog database can always be recovered, so long as the control file auto backup is available.
Physical Standby Database: A copy of the primary database that is updated with redo generated by the primary database. You can fail over to the standby database if the primary database becomes inaccessible. RMAN can create, back up, or recover a standby database. Backups that you make at a physical standby database are usable at the primary database or another physical standby database for the same production database. The recovery catalog is required when you use RMAN to back up a physical standby database. Note: A logical standby database is treated as a separate database by RMAN because it has a different DBID from its primary database.
Oracle SBT Libraries (Media Management Software): A vendor-specific application that enables RMAN to back up to a storage system such as tape. RMAN is preconfigured to use disk as the default device type. To create backups on non-disk media, you must use media and allocate channels supported by this software. RMAN contacts the media manager whenever the channel type allocated is not DISK. RMAN uses the Oracle Database Cloud Backup Module as the SBT interface to back up databases to OCI Object Storage, and the Oracle Secure Backup SBT interface to back up databases to tape devices.
Oracle Enterprise Manager: A browser-based platform to manage Oracle Database deployments, including backup and recovery through RMAN. The RMAN client and Enterprise Manager console run on separate computers.
Fast Recovery Area: A disk location that you can use to store recovery-related files such as control files, online redo log copies, archived redo logs, flashback logs, and RMAN backups. Oracle Database and RMAN manage the files in the fast recovery area automatically.
Oracle Secure Backup is a centralized, network based backup management application that backs up both Oracle AI Databases and file-system data across Linux, UNIX, and Windows operating systems. Oracle Secure Backup can centrally manage backup and restore operations of distributed, mixed-platform environments to tape, disk pool, and cloud storage devices. For Recovery Manager (RMAN), the Oracle Secure Backup serves as a media manager or the SBT interface that enables RMAN to send encrypted backups directly to tape. Oracle Enterprise Manager provides a unified interface for RMAN and Oracle Secure Backup. Managing tape devices, disk pools, and media servers using Oracle Enterprise Manager is exclusive to Oracle Secure Backup.
Oracle Secure Backup has ongoing support added for most major brand tape drives and libraries in Storage Area Network (SAN) and SCSI environments.
Oracle Secure Backup manages the backup and restore operations for heterogeneous environments by organizing the host computers into an administrative domain. The administrative domain consists of one administrative server, one or more media servers, and one or more clients.
The administrative server contains configuration information about all the hosts in the domain. It also stores the backup catalog that contains metadata about the backup and restore operations. You can have only one administrative server in an administrative domain.
A media server is a host that has secondary storage devices attached to it. It manages the movement of data to and from the secondary storage devices. Media servers can be directly attached to SAN-attached disk pools or tape drives that are either standalone or contained in tape libraries.
Any host in the administrative domain containing data that needs to be backed up is referred to as a client. Clients can include Oracle Databases and file-system data, they can be NDMP NAS servers, Linux, UNIX, or Windows hosts.
Oracle Secure Backup supplies an SBT interface that RMAN can use to back up database files to tape. You can use the RMAN command line client or Oracle Enterprise Manager interface to perform RMAN backup and recovery operations with Oracle Secure Backup. You use regular RMAN restore and recover operations to restore a database.
A file-system backup is initiated through the Oracle Secure Backup Web tool or obtool commands. A file-system backup can include any file on the file system. You use the Web tool to schedule automatic backups or to perform on-demand backup of filesystems. You can use the Oracle Secure Backup to restore file system data using a catalog-based restore operation or a raw restore operation.
Oracle Secure Backup supports storing data in OCI Object Storage. The cloud storage is useful for data that the user accesses infrequently, but is made available when needed.
The Oracle Secure Backup Cloud Module is part of the Oracle Secure Backup product family and provides the flexibility to back up your database to the Amazon S3 Cloud and to tape. With this cloud offering, local disk backups are sent directly to Amazon S3 for offsite storage and are fully integrated with Recovery Manager (RMAN) features and functionality.
Oracle Secure Backup maintains backup metadata for all RMAN and file-system backup operations on the administrative server.
The Zero Data Loss Recovery Appliance receives incremental backups and redo data from multiple protected databases.
Each separate data file that is backed up to a Recovery Appliance has its own separate delta pool. The delta pools reside in the delta store. The delta store is the sum total of all Recovery Appliance storage that is used to store protected database backup data. All data file and archived redo log backups are stored in the delta store. Database Backups are compressed to optimize storage utilization before they are stored in the delta store. Recovery Appliance continuously validates backups at the database block level thus assuring recoverability of data.
The Recovery Appliance receives an initial full backup followed by successive incremental backups for a database, and then constructs a virtual full backup which is a complete database image as of one distinct point in time. The Recovery Appliance indexes incremental backups and stores them in delta pools. Recovery Appliance stores backups in a centralized disk pool.
Real-time redo transport is the continuous transfer of redo changes from the system global area (SGA) of a protected database to a Recovery Appliance. Real-time redo transport enables RMAN to provide a recovery point objective (RPO) near 0. Typically, RMAN can recover to within a second of the time when the failure occurred. Protected databases write redo entries directly from memory to the Recovery Appliance as they are generated.
Recovery Appliance uses a policy-based backup management strategy that helps to achieve recovery window goals. Recovery Appliance supports using a variety of protection policies to suit the data protection requirements of each protected database. The default protection polices are Platinum, Gold, Silver, and Bronze. Each protection policy specifies different values for the disk and tape recovery windows. For example, the bronze policy supports a disk recovery window of 3 days and a 30 day recovery window for tape backups. The Gold policy additionally provides databases with real-time redo transport protection, whereas the Bronze policy does not. You can also associate multiple protected databases to a single protection policy.
The Recovery Appliance metadata database is the Oracle database that runs inside of the Recovery Appliance. It stores configuration data such as definitions, protection policy definitions, and client database definitions. The metadata database also stores backup metadata and contains the Recovery Appliance catalog. Each database protected by a Recovery Appliance must use the recovery catalog in the Recovery Appliance metadata database.
Oracle Secure Backup, the tape management component of Recovery Appliance, is preinstalled on the Recovery Appliance and is used to archive backups to an attached tape library.
Oracle Enterprise Manager Cloud Control (Cloud Control) provides a unified backup management interface for the entire life cycle of backups. You can use Cloud Control to back up, recover, and report on protected databases. As part of the disaster recovery strategy, Recovery Appliance can replicate protected database backups to other Recovery Appliances.
Recovery Service can archive protected database backups to OCI Object Storage Archive buckets for long-term backup retention.
When you configure replication, a Recovery Appliance (called the upstream Recovery Appliance) forwards backups to another Recovery Appliance (called the downstream Recovery Appliance). Recovery Appliance supports a wide variety of replication topologies.
The Oracle Cloud Infrastructure (OCI) Object Storage service is an internet-scale, high-performance storage platform where you can safely and securely store or retrieve data directly from the internet or from within the cloud platform.
In OCI Object Storage, Buckets are logical containers for storing data or objects. A bucket is governed by security policies to secure your backups from unauthorized access. Retention rules, applied to buckets, provide regulatory compliance and protect data from malicious damage.
The Archive storage tier is "cold" storage used for data seldom or rarely access, but that must be retained and preserved for long periods of time.
By default, Buckets are encrypted with keys managed by Oracle.
You configure your RMAN environment to send RMAN database backups to the OCI Object Storage buckets. You can then use familiar Recovery Manager (RMAN) commands to perform backup, restore, recovery, and maintenance operations. You can preserve RMAN backups by storing the backups in immutable buckets.
Protected databases backing up to a Recovery Appliance that archives to Object Storage. Recovery Appliance also uses the Database Cloud Backup Module to archive backups to Oracle Cloud for long term storage. The Oracle Key Vault (OKV) contains the TDE master keys for each protected database.
Oracle Cloud Databases can enable the OCI-managed automatic backups to Object Storage. You must use a service gateway to enable Oracle Cloud Databases to access Object Storage for backups. A service gateway allows connectivity to the Object Storage public endpoints from private IP addresses in private subnets.
Object Storage offers distinct storage class tiers to address the need for both performant, frequently accessed "hot" storage, and rarely accessed "cold" storage.
Every object uploaded to Object Storage is assigned to a storage tier. The storage tier property of the object determines its storage costs and any associated retrieval fees.
The Standard tier is the primary, default storage tier used for Object Storage service data. The Standard storage tier is "hot" storage used for data that you need to access quickly, immediately, and frequently. Data accessibility and performance justifies a higher price to store data in the Standard tier.
The Archive tier is the primary, default storage tier used for Archive Storage service data. The Archive storage tier is "cold" storage used for data seldom or rarely access, but that must be retained and preserved for long periods of time.
You choose a default storage tier (Standard or Archive) when you create a bucket. When set at bucket creation, you cannot change the default storage tier for a bucket.
Object Storage enables you to configure retention rules at the bucket level and are applied to all individual objects in the bucket. Retention rules provide immutable, WORM-compliant storage options for data written to Object Storage and Archive Storage for data governance, regulatory compliance, and legal hold requirements. Retention rules can also protect your data from accidental or malicious update, overwrite, or deletion. Retention rules can be locked to prevent rule modification and data deletion or modification even by administrators.
Oracle Database Autonomous Recovery Service offers secure backup automation and enhanced data protection capabilities for OCI databases. Recovery Service is designed to leverage the combined capabilities of the Oracle Zero Data Loss Recovery Appliance and Oracle Recovery Manager (RMAN). You can offload all backup processing and storage requirements to Oracle Database Autonomous Recovery Service, thereby eliminating backup infrastructure costs and manual administration overhead.
Autonomous Recovery Service supports backups and data protection for Oracle Cloud Databases including multicloud Oracle Databases such as Oracle Database@Azure and Oracle Database@Google Cloud. The OCI Console provides a unified interface to define your backup strategy using Recovery Service resources.
Recovery Service centralizes backup storage in Oracle Cloud (default cloud backup location for protected databases). A protection policy based mechanism controls your backup storage demands. You do not need to perform any manual tasks to address storage utilization or monitoring.
Recovery Service requires a private subnet for backup and recovery operations in each database virtual cloud network (VCN) within your tenancy. Oracle recommends that your database VCN includes at least one private subnet dedicated for backups to Recovery Service. You can then register a Recovery Service subnet to allow Recovery Service to access databases in the VCN.
You can implement access control by assigning Oracle Cloud Infrastructure (OCI) policies. In the Console, use the Policy Builder to select Autonomous Recovery Service as the Policy Use Case, and then select the predefined policy templates. Policies permit Recovery Service to access databases in a chosen VCN and also allows the supported OCI database services or multicloud Oracle Databases to use Recovery Service for data protection. For example, use the Ability to do all things with Autonomous Recovery Service policy template to allow a Oracle Database service to use Recovery Service. Use the Let Oracle Database@Azure use Autonomous Recovery Service for backup policy template to allow an Oracle Database@Azure resource to use Recovery Service.
Recovery Service retains protected database backups for a minimum period of 14 days and a maximum period of 95 days. You can either choose the Oracle-defined policies (Platinum, Gold, Silver, or Bronze) that support common use cases for data retention, or create custom policies to suit your demands for backup retention. You can optionally enforce a retention lock on the backup retention period so that Recovery Service can prevent the modification or deletion of backups until the retention period ends. Retention lock is an optional feature to safeguard your protected database backups from inadvertent changes or malicious damages, such as ransomware attacks.
Recovery Service supports multicloud Oracle Databases and provides the flexibility to store backups either in Oracle Cloud (default backup storage location) or in the same cloud location where the database resides. By default, Recovery Service stores protected databases and related backups in Oracle Cloud. If you enable the Store backups in the same cloud provider as the database option for a protection policy, then Recovery Service stores the policy-linked protected database and its backups in the target database cloud location instead of Oracle Cloud. For example, for Oracle Database@Azure, Recovery Service stores the associated protected database backups in Azure if you have selected the Store backups in the same cloud provider as the database in the protection policy.
Auto-backup replication is used for backup high-availability within a region. You can restore to any availability domain, zone, or region.
Recovery Service offers the real-time data protection feature that enables protected databases to minimize the possibility of data loss. A protected database can continuously transfer redo logs to Recovery Service and achieve a recovery point objective (RPO) near the last sub-second. Real-time data protection is an extra cost option.
You can also use the Oracle Cloud Infrastructure Monitoring service, including Alarms, to monitor database protection status and storage utilization.
Recovery Service uses the Oracle Cloud Infrastructure Audit service, which automatically records calls to Recovery Service application programming interface (API) endpoints as log events.
