This chapter provides an overview of Zero Data Loss Recovery Appliance, commonly known as Recovery Appliance, and describes the high-level steps required to use Recovery Appliance for data protection.
This chapter contains the following topics:
Recovery Appliance is a cloud-scale Engineered System designed to protect all Oracle Databases in your enterprise. Built on a scalable architecture and integrated with Recovery Manager (RMAN), it uses a fully fault-tolerant and scalable hardware to provide a centralized, incremental-forever backup strategy for a large number of databases.
Recovery Appliance provides enhanced data protection and availability for the enterprise. Real-time redo transport enables data protection to the last sub-second, dramatically reducing recovery point objectives across the entire enterprise. Backup and restore processing is offloaded to the Recovery Appliance thus freeing production database resources and boosting their performance.
Backups are stored and managed in a centralized disk pool. An initial full backup followed by successive incremental backups is sufficient to protect your production databases. Incremental backups are indexed and stored as they are received by the appliance. Recovery Appliance provides virtual full backups, each of which is a complete database image as of one distinct point in time, to recover databases to any specified time within the recovery window. Virtual full backups are automatically created by Recovery Appliance for every incremental backup that it receives. Virtual backups enable the rapid reconstruction of a full backup to a point-in-time within the user's recovery window.
The Recovery Appliance metadata database manages the metadata for all backups stored on the Recovery Appliance and contains the Recovery Appliance catalog.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for more information about Recovery Appliance architecture and features
A client database whose backups are managed by a Recovery Appliance is called a protected database. Each protected database uses a specific Recovery Appliance as a destination for centralized backup and recovery. Protected databases use RMAN commands to perform backup and recovery operations. You must install the Zero Data Loss Recovery Appliance backup module (Recovery Appliance backup module), an Oracle-supplied SBT library, that enables RMAN to transfer protected database backups over the network to a Recovery Appliance.
This section contains the following topics:
Figure 1-1 illustrates the Recovery Appliance environment. Multiple protected databases are backed up to a Recovery Appliance using an incremental-forever backup strategy. You can also configure protected databases to transfer real-time redo data to the Recovery Appliance. The Recovery Appliance environment can include protected databases from Oracle Database 10g, Oracle Database 11g, and Oracle Database 12c. To enable protected databases to access and store backups to the Recovery Appliance, you must configure databases as described in "Configuring Protected Databases".
See Also:
"About the Recovery Appliance Incremental-Forever Backup Strategy"
Zero Data Loss Recovery Appliance Administrator's Guide for the supported Oracle Database releases
Figure 1-1 Recovery Appliance Architecture and Protected Databases
The Recovery Appliance receives incremental backups and redo data from multiple protected databases. It continuously validates backups at the Oracle block level thus assuring recoverability of data. Backups are compressed to optimize storage utilization before they are stored 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. Recovery Appliance creates virtual full backups of the protected database, which is a complete database image as of one distinct point in time.
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.
See Also:
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. 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.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for information about replicating protected database backups
Minimizes the impact of backups on production servers
Minimizes backup windows
Recovery Appliance simplifies data protection for databases across the enterprise by reducing backup windows and providing a single repository for backups of multiple protected databases. Recovery Appliance uses an incremental-forever backup strategy in which only one level 0 backup is required for each protected database. Subsequently, protected databases send level 1 incremental backups to the Recovery Appliance.
Offloads backup processing from production servers
Most backup processing, including backup validation and backup maintenance operations are offloaded to the Recovery Appliance. Performance of production systems is improved because resources uses for backup processing are freed up.
Eliminates data loss
Transports redo data asynchronously to Recovery Appliance
Real-time redo transport enables protected databases to recover data to within a few subseconds of a database failure. It minimizes the window of potential data loss that exists between successive incremental archived log backups by writing redo data directly, as it is generated, from the protected database memory to the Recovery Appliance. See Zero Data Loss Recovery Appliance Administrator's Guide for information about the Oracle Database releases that support real-time redo transport.
Protects against data corruption
Backups created to Recovery Appliance are continuously validated to ensure that database backup integrity is maintained. With Oracle RMAN block checks, Automatic Storage Management (ASM) and Exadata data checks, Recovery Appliance provides the best protection for Oracle databases far exceeding third-party solutions that rely mostly on hardware checksums.
Integration with Oracle high availability technologies
Recovery Appliance is integrated with Oracle high availability technologies including Recovery Manager (RMAN), Oracle Real Application Clusters (Oracle RAC), Oracle Data Guard, and Oracle Secure Backup. You can use RMAN commands, with the exceptions noted in Differences in RMAN Commands, to back up and recover protected databases.
Reduced restore and recovery time
Recovery Appliance uses virtual full backups that are created on-demand to reduce the restore and recovery time. A virtual full backup is a complete database image as of a distinct point in time. Recovery Appliance efficiently maintains virtual full backups by indexing the incremental backups from protected databases.
Optimizes storage requirements
Backup storage no longer needs to be distributed across all the protected databases. Recovery Appliance uses a shared disk backup pool to store backups for multiple protected databases.
Despite moving your backups to Recovery Appliance, you still need to configure a local fast recovery area on the protected databases to store control files, online redo log files, archived redo logs, and flashback logs. However, this fast recovery area can be considerably smaller because it does not need to store backups.
In a conventional Oracle Database deployment, a DBA or team of DBAs would be responsible for database administration as well as for planning and performing backup and recovery activities. The storage administrator manages the storage requirements and database backups. By centralizing backup storage and management, Recovery Appliance provides DBAs with full visibility into the end-to-end enterprise backup lifecycle, from the protected database to Recovery Appliance to tape.
The protected database administrator is responsible for performing the following tasks:
Planning backup and restore strategies for the protected database
Some of the considerations during the planning stage include deciding acceptable recovery window goals and retention policies for the protected database, estimating the storage space required to store protected database backups, and deciding on the method used to send backups to the Recovery Appliance.
When you move your protected database backups to Recovery Appliance for the first time, you must design a strategy to migrate to the Recovery Appliance.
Configuring protected database access to the Recovery Appliance
Before using Recovery Appliance for data protection of your protected database, you must configure backup and recovery settings as per the protected database requirements.
See Also:
Performing backup and recovery operations
Backup jobs are used to perform protected database backup operations. Backup jobs can run immediately or be scheduled to run at a later time. Recovery operations are typically performed immediately in response to media or data loss incidents.
See Also:
Backup operations to the Recovery Appliance require coordination between an RMAN client running on the protected database and the system software running on the Recovery Appliance. This section describes the users and privileges necessary for Recovery Appliance backup operations.
The protected database administrator is a user with SYSDBA
or SYSBACKUP
privileges on the protected database. This user connects to a Recovery Appliance to perform backup, restore, and recovery operations for the protected database.
With Oracle Database 12c, all RMAN backup and recovery operations can be performed with either SYSBACKUP
or SYSDBA
privileges. With releases of Oracle Database earlier than Oracle Database 12c, the protected database administrator must have SYSDBA
privileges to perform RMAN backup and recovery operations.
To authenticate with a Recovery Appliance and perform backup and recovery operations, the protected database administrator must be associated with a Recovery Appliance user.
A Recovery Appliance user is a database user account, created in the Recovery Appliance metadata database by the Recovery Appliance administrator. This account has the privileges required to send and receive backups for one or more protected databases that are registered with the Recovery Appliance and to manipulate the Recovery Appliance catalog metadata for these protected databases. This is also the account to use to send redo data from a protected database to the Recovery Appliance.
The Recovery Appliance metadata database contains multiple Recovery Appliance user accounts. Each Recovery Appliance user owns a virtual private catalog and can access and modify only those rows in the Recovery Appliance catalog that pertain to databases to which it has been granted access. The authentication credentials of the Recovery Appliance user are stored securely in an Oracle Wallet on the protected database host. The protected database administrator connects to the Recovery Appliance user using the catalog role.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for information about the different Recovery Appliance user accounts
Recovery Appliance uses protection policies to simplify the management of protected database backups. A protection policy is a collection of attributes that defines recovery goals and storage space requirements for one or more protected databases. A Recovery Appliance contains multiple protection policies that define varied recovery goals. Each protected database is assigned exactly one protection policy that determines how the Recovery Appliance stores and maintains backup data for that protected database.
A protection policy defines the following attributes for each protected database that is associated with the protection policy:
A Recovery Appliance storage location for storing the protected database backups
The recovery window goal for disk backups
(Optional) Whether backups protected by this policy must be replicated or written to tape before being considered for deletion
(Optional) The recovery window for tape backups
(Optional) A backup polling policy
Protection policies enable you to group protected databases by recovery service tier. For example, tier 1 databases require backups to be retained for 14 days on disk and 30 days on tape. You create a protection policy that defines these recovery window goals and then assign it to all tier 1 protected databases.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for information about creating and maintaining protection policies
Protected database backups can be stored on Recovery Appliance using one of the following techniques:
Protected databases send backups directly to a Recovery Appliance
The protected database administrator authenticates and connects to a Recovery Appliance and then backs up the protected database to the Recovery Appliance. The Recovery Appliance backup module is used to send backups over the network to the Recovery Appliance. The incremental-forever backup strategy is used to back up protected databases to the Recovery Appliance. If required, you can configure real-time redo transport to transmit redo data directly to the Recovery Appliance.
Before you send protected database backups to a Recovery Appliance, you must enroll the protected database with the Recovery Appliance and configure settings.
Recovery Appliance automatically picks up protected database backups from a shared location
Instead of directly interacting with a Recovery Appliance, the protected database writes backups to a configured shared storage location. The Recovery Appliance uses backup polling, described in "Overview of Backup Polling", to periodically check the shared storage location and pick up new backups stored in this location.
Backup polling enables a Recovery Appliance to periodically poll a predefined shared disk directory, called the backup polling location, and pick up new protected database backups that are placed in this location. The protected database administrator does not interact with the Recovery Appliance to send backups. Instead, backups are placed in the backup polling location and the Recovery Appliance periodically checks and picks up these backups.
The backup polling location can store level 0, level 1, and archived redo log backup sets. It is accessible to the Recovery Appliance through Network File System (NFS).
A backup polling policy, created on the Recovery Appliance, defines a path to the backup polling location and the frequency at which the Recovery Appliance polls this location. The polling policy is associated with a protected database through a protection policy.
See Also:
"Setting Up Backup Polling to Migrate Existing Backups to the Recovery Appliance"
Zero Data Loss Recovery Appliance Administrator’s Guide for information about creating and assigning backup polling policies
The Recovery Appliance metadata database, which resides on the Recovery Appliance, manages the backup metadata for all protected databases registered with the Recovery Appliance and also contains the Recovery Appliance catalog. Every protected database that stores backups on the Recovery Appliance must use the Recovery Appliance catalog. However, protected databases can use the Recovery Appliance catalog without also using the Recovery Appliance as a backup repository. Protected database administrators connect to the Recovery Appliance catalog using the same Recovery Appliance user that is used for backup and recovery operations.
After you enroll a protected database with a Recovery Appliance, you must register it with the Recovery Appliance catalog. Registering the protected database stores backup metadata for the protected database in the Recovery Appliance catalog. Existing backup metadata that is currently stored in the protected database's RMAN recovery catalog must be imported into the Recovery Appliance catalog as described in "Importing Protected Database Metadata into the Recovery Appliance Catalog".
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for information about the Recovery Appliance metadata database
Each protected database that stores backups to a Recovery Appliance must have a globally unique database name (DB_UNIQUE_NAME
). This global database name is used to identify the protected database to which a backup belongs. Backups for a protected database are written to the storage location that is specified in the protection policy associated with the protected database.
This section contains the following topics:
To perform protected database backup and recovery operations, you must use one or more RMAN SBT channels that correspond to the Recovery Appliance backup module. This backup module is the shared library that transfers backup data to and from the Recovery Appliance.
Protected database backups are sent over the network to a shared disk. Using a single RMAN channel may not provide optimal performance because of possible network latencies. It is recommended that you use between 2 and 4 RMAN channels for each backup client.
You can either configure an SBT channel that corresponds to the Recovery Appliance backup module or allocate RMAN SBT channels explicitly for each backup or recovery operation.
Use the RMAN BACKUP
command to back up protected databases to Recovery Appliance. When you back up a protected database to the Recovery Appliance for the first time, you must seed the repository by creating an initial level 0 backup of the entire database. A level 0 incremental backup must also be created when point-in-time recovery is performed on the protected database to a time before the oldest backup that exists on the Recovery Appliance.
After the first level 0 backup, your regular backup schedule will consist of creating periodic level 1 cumulative incremental backups of the protected database, the spfile, control files, and archived redo log files as described in "About the Recovery Appliance Incremental-Forever Backup Strategy". Since archived logs hold records of all changes that occur in the database, these critical files must be backed up more frequently than data files. Frequent archived redo log backups reduce the potential data loss that is incurred, if the protected database is lost and backups need to be recovered.
You can either back up directly to the Recovery Appliance or first create backup sets in a local fast recovery area or disk directory and then copy them to the Recovery Appliance using the BACKUP BACKUPSET
command.
A good backup strategy must ensure that backups created can actually be restored and used successfully. Because Recovery Appliance validates incoming backups for Oracle block correctness before storing them, you need not include a RESTORE VALIDATE
command in your periodic full restore and recovery testing. Even virtual backups are periodically validated in-place by a background task running on the Recovery Appliance.
You can configure protected databases to use backup encryption. If a backup is encrypted during an RMAN backup operation to Recovery Appliance, then the backup remains encrypted on the Recovery Appliance. A subsequent copy of this backup to tape will also remain in an encrypted format. However, Oracle recommends that you avoid using RMAN backup encryption when performing backups to Recovery Appliance. Encrypted backups are not ingested by Recovery Appliance and cannot be used to construct virtual full backups or be part of an incremental-forever backup strategy.
Backups that are copied to tape from the Recovery Appliance can be encrypted using hardware-based encryption on tape drives or using Oracle Secure Backup.
See Also:
Oracle Secure Backup Administrator's Guide for information about hardware-based encryption
When restoring protected databases using backups stored on Recovery Appliance, a full backup is created from the corresponding virtual backup. The Recovery Appliance catalog is used to determine the most appropriate full virtual backup that can be used, based on the point-in-time specified for the recovery. The Recovery Appliance receives the restore request, constructs the physical backup sets from the appropriate virtual backups, and then sends these backup sets to the protected database through the SBT channels that was allocated earlier. On the protected database, RMAN validates the received backup sets and uses them to perform the restore operation. The RMAN RESTORE
command enables you to restore protected databases using Recovery Appliance.
When the RMAN RECOVER
command is used, the Recovery Appliance catalog is used to determine the appropriate archived log backups that are required to recover the restored data files to the desired point in time. Frequent level 1 incremental backups reduce the number of archived redo logs that need to be applied in case of a failure and this reduces recovery time. Recovery Appliance sends the required backups to the protected database which uses them to recover to a consistent point and to be subsequently opened. If real-time redo transport is configured for the protected database, then the most current archived redo logs are available and the database can be completely recovered with only sub-seconds worth of data loss.
While Recovery Appliance can support many different RMAN backup strategies, Oracle strongly recommends using the incremental-forever backup strategy to back up protected databases. This strategy is based on an initial level 0 incremental backup followed by successive level 1 cumulative incremental and archived redo log backups. Apart from the initial full backup, no regular full backups are required. This eliminates traditional backup windows and improves protected database performance.
For each protected database, Recovery Appliance regularly receives scheduled level 1 incremental backups consisting of only the data file block changes relative to the most recent virtual full backup (recorded as level 0 in the recovery catalog). The level 1 backups are validated to ensure that there are no corrupt data blocks, compressed using specialized block-level algorithms, and then written to a storage pool on the Recovery Appliance. Virtual full backups are created based on the incoming incremental backups. When you need to recover the protected database, Recovery Appliance uses virtual full backups and archived log backups that together allow the recreation of all database changes until the specified recovery time.
You must include archived redo logs in both full and incremental backups. Oracle recommends that you take frequent backups of the archived redo log files and include them in your level 1 incremental backups. Backing up archived redo logs is not required if you configure the protected database to use real-time redo transport (See "About Real-Time Redo Transport").
There are important differences between the incremental strategy used in a conventional RMAN setup and the incremental-forever backup strategy used with Recovery Appliance:
The RMAN incrementally updated backup strategy uses an initial image copy, followed by successive level 1 incremental backups. The image copy is then updated by merging the level 1 incremental backups with the image copy.
Following is an example of a script that is used to implement the RMAN incrementally updated backup strategy:
run { RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; }
With the Recovery Appliance incremental-forever backup strategy, only one level 0 incremental backup is required. Subsequently, level 1 incremental backups are created and stored on the Recovery Appliance. A virtual full backup is created by referencing blocks from the initial level 0 and subsequent level 1 backups.
Following is an example of a script that implements the Recovery Appliance incremental-forever backup strategy:
BACKUP CUMULATIVE INCREMENTAL LEVEL 1 DEVICE TYPE sbt FORMAT '%d_%U' TAG '%TAG' DATABASE; BACKUP DEVICE TYPE sbt FORMAT '%d_%U' TAG '%TAG' ARCHIVELOG ALL NOT BACKED UP;
Redo data contains records of all changes made to a database and is therefore critical to minimizing data loss in the event of data failures. Using real-time redo transport substantially reduces the window of potential data loss that exists between successive archived redo log backups. When real-time redo transport is configured, archived redo log backups are transparent to the database administrator. The incoming redo stream from one or more protected databases is stored in the redo staging area on the Recovery Appliance. Protected databases can recover data up to the last change that the appliance received.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for information about Oracle Database releases for which real-time redo transport is supported
With real-time redo transport enabled, Recovery Appliance becomes a remote destination for asynchronous redo transport services, similar to a standby database in an Oracle Data Guard environment. Redo data from the protected database is written asynchronously to the Recovery Appliance as it is generated. Load on production database servers is minimized because redo data is shipped directly from the memory to the Recovery Appliance without the involvement of disk I/O. As the redo stream is received, compressed archived log backups are created in the protected database's storage location every time a log switch occurs. The archived log backups generated by the Recovery Appliance are recorded in the Recovery Appliance catalog as normal backups and can be restored and applied to data files using the RMAN RECOVER
command.
See Also:
Oracle Data Guard Concepts and Administration for information about asynchronous redo transport services
If the protected database crashes, redo data received from the current redo log group until the time of the crash is backed up at the Recovery Appliance as a "partial" archived redo log. If the protected database is reopened, crash recovery of the protected database will complete the current redo log group at the time of the crash, and the completed redo log will be re-shipped to the Recovery Appliance through the automatic Data Guard Gap fetching feature. The "complete" archived redo log will be used in any future restore/recover operations instead of the previously backed up "partial" archived redo log.
During recovery of a protected database, partial and complete archived logs are automatically restored as required to completely recover the protected database.
Real-time redo transport requires setup on the Recovery Appliance and the protected database. You need a redo transport user that will be used to authenticate and then send redo data from the protected database to the Recovery Appliance. This user must be the same as the Recovery Appliance user that will be used to send protected database backups to the Recovery Appliance. The credentials of this Recovery Appliance user are stored in an Oracle wallet on the protected database.
On the protected database, configure ARCHIVELOG
mode and set up an archive destination for redo data (using the LOG_ARCHIVE_DEST_
n
parameter) that points to the service name of the Recovery Appliance.
See Also:
Recovery Appliance provides multiple interfaces to manage backup and recovery operations for protected databases.
Oracle Enterprise Manager Cloud Control (Cloud Control)
Cloud Control provides a GUI for administering, managing, and monitoring a Recovery Appliance environment. It also enables you to configure, back up, and recover protected databases.
Additional information about using Cloud Control is available in the Cloud Control online help.
RMAN client
Recovery Appliance is integrated with RMAN and you can use the RMAN client installed on your protected database to configure, back up, and recover protected databases.
SQL*Plus
SQL*Plus is a command-line tool that you can use to query the Recovery Appliance catalog and run the DBMS_RA
PL/SQL package.
This section describes the high-level tasks in using Recovery Appliance to store and manage backups for multiple protected databases in the enterprise. These tasks can be performed using Cloud Control or RMAN. Depending on the management interface used, there may be minor variations in the steps to perform certain tasks.
See Also:
Zero Data Loss Recovery Appliance Administrator's Guide for the workflow to manage a Recovery Appliance environment
The task flow for setting up and using Recovery Appliance for enterprise data protection is as follows:
Decide on a strategy to migrate your protected database backups to Recovery Appliance as described in "Migration Considerations for Protected Database Administrators".
Enroll the protected database with a Recovery Appliance.
This step only needs to be performed the first time you configure your protected database to use a Recovery Appliance.
Configure backup and recovery settings for the protected database.
This is typically a one-time task that you perform while enrolling a protected database with a Recovery Appliance. However, you can modify backup and recovery settings subsequently.
Perform a test backup to verify that your protected database configuration is accurate.
It is recommended that you perform a test backup when configuration settings are initially set or subsequently modified.
See Also:
Back up the protected database to the Recovery Appliance.
You can schedule protected database backups to be performed at a specified time.
Perform test restore and recovery to assure yourself that the protected database can be recovered using the backups stored on the Recovery Appliance.
See Also:
In the event of a failure (caused by a media failure or data corruption), recover the protected database using backups stored on the Recovery Appliance.
Depending on the type of failure, you can recover the entire protected database or just the affected database files.