To forward backups to a downstream Recovery Appliance, the upstream Recovery Appliance uses the same Recovery Appliance Backup Module that a protected database uses to send backups. The basic steps for processing backups are as follows:

1. A protected database uses its Recovery Appliance Backup Module to send backups to the Recovery Appliance.

2. The Recovery Appliance receives the backups and processes them as normal.

3. The upstream Recovery Appliance forwards the backups to the downstream Recovery Appliance.

   Note:

   The downstream Recovery Appliance does not know that it serves in the downstream role. The logic for receiving and processing backups on the downstream Recovery Appliance is independent of what occurs on the upstream Recovery Appliance.

   Note:

   When real-time redo transport is enabled, incoming redo changes are not replicated in real time by Recovery Appliance. When an archived redo log backup is created, the Recovery Appliance automatically replicates this backup along with the data file backups.

4. As it receives backups from the upstream Recovery Appliance, the downstream Recovery Appliance updates its own metadata database.

5. The upstream Recovery Appliance requests metadata updates from the downstream metadata.

Periodically, the upstream Recovery Appliance requests metadata updates from the Recovery Appliances directly downstream from it. On receiving a metadata request, the downstream Recovery Appliance sends metadata updates to the upstream Recovery Appliance, which updates its own recovery catalog. In Recovery Appliance replication, this process is known as reconciling.

Because a downstream Recovery Appliance processes backups independently from the upstream Recovery Appliance, a downstream Recovery Appliance can have completely different policies for every database whose backups it is storing. This design allows for a wide variety of use cases to be configured. In general, the use case for replication is to preserve database backup and recovery operations in the event of an outage or loss of the local recovery appliance. The replication topologies described below illustrate how this can be achieved.

• One-Way

  Backup data from local protected database (DB-a) flows to an upstream Recovery Appliance (RA-x), which forwards it to a downstream Recovery Appliance (RA-y).

  
  Description of the illustration rep_oneway.png

• Bi-Directional

  Backup data from local protected databases (DB-a) flow to a local Recovery Appliance (RA-x), which then forwards them to a remote Recovery Appliance (RA-y). Conversely, backup data from remote database (DB-d) flow to a RA-y, which then forwards them to RA-x.

  Bi-directional replication is essentially one-way replication from RA-x to RA-y for a certain set of protected databases (DB-a,DB-b, DB-c), and also one-way replication the other direction from RA-y to RA-x for a different set of protected databases (DB-d, DB-e, DB-f).

  
  Description of the illustration rep_bidirectional.png

  In this case, each Recovery Appliance plays both the upstream and downstream roles in the replication topology. Every Recovery Appliance serves as the primary backup location for one set of protected databases, and the secondary backup location for the other set. In this way, every Recovery Appliance is actively utilized while also providing disaster recovery services for the other Recovery Appliance.

• Hub-and-Spoke

  Backups flow from one set of databases to a local Recovery Appliance, and from a different set of databases to a different local Recovery Appliances. The local Recovery Appliances then forward these backups to a single remote Recovery Appliance, which archives the backups to tape.

  
  Description of the illustration rep_hubspoke.png

• Backup Anywhere

  Two Recovery Appliances RA-x and RA-y replicate between each other, and are the upstream and downstream of each other. Backups from databases DB-a and DB-b flow to their upstream Recovery Appliance, respectively RA-x and RA-y. Then RA-x and RA-y replicate these backups to their downstream Recovery Appliance, respectively RA-y and RA-x. Backups from databases DB-a and DB-b can be sent to either RA-x or RA-y with replication occurring to the Recovery Appliance which did not receive the backups directly from the DB.

  
  Description of the illustration rep_backupanywhere.png

• Read-Only Replication

  The read_only replication mode is useful when changing the destination Recovery Appliance for database backups from the original RA-x to a different RA-y while RA-x remains available to RA-y. This eliminates the need to replicate the old backups from RA-x to RA-y, which is time consuming and network intensive. If the original RA-x is available to RA-y, a replication server configuration in read_only mode can be added to the protection policy on RA-y which designates RA-x as the downstream. All backups for the databases in the policy that exist on the downstream are retrievable when and if needed by the upstream. After the old backups on the original RA-x have expired according to the protection policy, RA-y no longer needs the backups on RA-x which allows RA-x to be removed from the replication topology.

  
  Description of the illustration rep_readonly.png

  A key use case for read_only replication is for introducing new Recovery Appliances into a replication configuration, so that the original Recovery Appliances can be decommissioned or so that protected database workload can be scaled out across additional Recovery Appliances. This allows for the graceful transfer of backup / restore between Recovery Appliances without unnecessary transmission and duplication of old backup files.

• Request Mode Replication

  In request_only mode replication, the upstream (RA-x) Recovery Appliance receives the primary database backups while the downstream (RA-y) receives the standby database backups, redo logs, and archive logs. When the upstream RA-x is offline for planned maintenance as one example, the primary database redo and archive logs are redirected to the downstream RA-y, where new archived log backups are created in order to preserve database recoverability. Redo and archived logs are the more critical data to retrieve from the upstream databases, because the database can hang if the local archived log directory fills up. Therefore, they are transmitted to RA-y so that they can be safely deleted by RMAN on DB-a.

  The command RMAN CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP 1 TIMES establishes that when redo has been shipped and backed up on RA-y, then RA-x can safely delete the local archived logs to reclaim space. With this policy configured, the command RMAN DELETE ARCHIVELOG can also be used to safely reclaim local archived log space.

  RA-y is not affected by RA-x outage and still receives level 1 backups from standby database as normal. Standby backups on RA-y can be used for primary database restores. When RA-x comes back online, all previously redirected backups are replicated from the downstream RA-y to the upstream RA-x to re-establish its full recoverability of its databases.

  
  Description of the illustration rep_request.png

• Cascade Mode Replication

  Any of the preceding use cases could be adapted for cascaded replication, in which an upstream Recovery Appliance replicates to a downstream Recovery Appliance, which in turn replicates to another Recovery Appliance, creating a one-way chain of Recovery Appliances.

  
  Description of the illustration rep_cascade.png