Backup Anywhere offers Expanded Replication
for High Availability and More Flexibility
- Backup Anywhere - Providing the ability to change roles (upstream
vs downstream).
- Read Only replication - Providing seamless migration to a different Recovery
Appliance.
- Request Only Replication - Providing a High Availability option for backups.
Backup Anywhere
Backup
Anywhere provides even more options for HADR (High Available/Disaster Recovery)
with the ability to redirect backups and redo to another Recovery Appliance. In
addition, Backup Anywhere provides the ability to perform a role reversal,
removing the concept of upstream/downstream. As the name implies, when
replicating between two or more Zero Data Loss Recovery Appliances you can
switch the Recovery Appliance that is receiving backups from your
protected databases.
With
Backup Anywhere you configure two Recovery Appliance as pairs and create
replication servers that point to each other. The metadata
synchronization will ensure backups are replicated to its pair and ensures the
Replication Appliance pairs stay in sync.
NOTE:
In order to use Backup Anywhere you must use the new REPUSER naming convention
of REPUSER_FROM_<source>_TO_<destination>.
For
my example, the diagram below depicts a three Zero Data Loss
Appliance architecture with the primary databases in New York sending backups
to the Recovery Appliance in the New York Data Center, The Recovery
Appliance in the New York Data Center replicates backups to the Recovery
Appliance in the London Data Center. And finally, the Recovery Appliance in the
London Data Center replicates backups to the Recovery Appliance in Singapore.
New
York --> London --> Singapore
But
what happens If I want to change which Recovery Appliance I am sending
my backups to? With Backup Anywhere I can change the Recovery Appliance
receiving backups, and the flow of replicated backups will be taken care of
automatically. With Backup Anywhere the Recover Appliances will
seamlessly change the direction of the replication stream based on which
Recover Appliance is currently receiving the backups. Backup Anywhere
does this automatically and will still ensure backups on the three Zero
Data Loss Appliances are synchronized and available
Singapore
--> London --> New York.
Read Only Replication
This
is my favorite new feature included in the latest Recovery Appliance release.
Read Only allows you to easily migrate your backups to
a new Recovery Appliance while leaving the older backups still
available.
Replication
normally synchronizes the upstream catalog with the downstream catalog AND
ensures that backups are replicated to the downstream. With Read Only
Replication, only the synchronization occurs. The upstream Recovery
Appliance (typically the new RA) knows about the backups on the downstream
Recovery Appliance (the old RA). If a restore is requested that is not on
the upstream Recovery Appliance, the upstream will pull the backup from the
downstream.
The
most common use case is retiring older pieces of equipment, but Read Only
Replication can be used for additional use cases.
- Migrating backups to a new datacenter
- Migrating backups for a subset of database from an
overloaded Recovery Appliance to a new Recovery Appliance to balance the
workload
Replace older
Recovery Appliance
In
this example I want to replace the current Recovery Appliance (ZDLRAOLD) with a
new Recovery Appliance (ZDLRANEW). During this transition period I want
ensure that backups are always available from the protected database.
This example will show the migration of backups from ZDLRAOLD to ZDLRANEW. I am
keeping 30 days of backups for my databases and I am starting the migration
on September 1.
Step #1 - September
1, configure replication from ZDLRAOLD to ZDLRANEW
Create a
replication server from ZDLRAOLD to ZDLRANEW and add the policy(s) for the
databases to the replication server. This will replicate the most current
level 0 backup (FULL) onto ZDLRANEW for all databases without changing
the backup location from the protected databases.
Once
you have ensured that all databases have replicated a level 0 backup to
ZDLRANEW you can remove the replication server from ZDLRAOLD which will
stop the replication.
Step #2 - September 2,
configure Read Only replication from ZDLRANEW to ZDLRAOLD
Create
a replication server from ZDLRANEW to ZDLRAOLD. Add the policies all databases
to the replication server and ensure that the read only flag is set when adding
the policy.
PROCEDURE add_replication_server (
replication_server_name IN VARCHAR2,
protection_policy_name IN VARCHAR2
skip_initial_replication IN BOOLEAN DEFAULT FALSE,
read_only IN BOOLEAN DEFAULT FALSE,
request_only IN BOOLEAN DEFAULT FALSE);
Note: The Read Only
flag must be set when adding the policy to the replication server to ensure
backups are NOT replicated from ZDLRANEW to ZDLRAOLD.
Step #3 - September 3,
configure backups from the protected databases to backup to ZDLRANEW.
At
this point ZDLRANEW should contain at least 1 full backup for all databases,
and the incremental backups will begin on September 3rd. ZDLRANEW will
now contain backups from September 1 (when replication began) until the
most current Level 0 virtualized backup taken. ZDLRAOLD will contain
backups from August 4 until September 2nd when protected database backups to
ZDLRAOLD were moved to be sent to ZDLRANEW.
Step #4 - September
4+, ZDLRANEW contains all new backups and old backups age off ZDLRAOLD
Below
is a snapshot of what the backups would look like 15 days later on September
15th. Backups are aging off of ZDLRAOLD and ZDLRANEW now contains 15 days
of backups.
Step #5 - September
15, Restore backups
To
restore the protected database using a point in time you would connect the
protected database to ZDLRANEW and ZDLRANEW would provide the correct virtual
full backup regardless of its location.
1. If the Full backup prior to the point-in-time
is on ZDLRANEW it is restored directly from there.
2. If the Full backup is NOT on ZDLRANEW, it will
get pulled from ZDLRAOLD through ZDLRANEW back to the protected database
The
location of the backups is transparent to the protected database, and ZDLRANEW
manages where to restore the backup from.
Step #6 - September
30 Retire ZDLRAOLD
At
this point the new Recovery Appliance ZDLRANEW contains 30 days of backups and
the old Recovery Appliance ZDLRAOLD can be retired.
Request Only Mode
Request
Only Mode is used when Data Guard is present and both the Primary database and
the Data Guard database are backing up to a local Recovery Appliance. The
two Recovery Appliances synchronize only
the metadata, no backup pieces are actively replicated. But, in the
event of a prolonged outage of either Recovery Appliance, this features
provides the ability to fill gaps by replicating backups from its paired
Recovery Appliance.
To
implement this feature, replication servers are configured on both Recovery
Appliances, and the policies are added to the replication server
specifying REQUEST_ONLY=TRUE.
PROCEDURE add_replication_server (
replication_server_name IN VARCHAR2,
protection_policy_name IN VARCHAR2
skip_initial_replication IN BOOLEAN DEFAULT FALSE,
read_only IN BOOLEAN DEFAULT FALSE,
request_only IN BOOLEAN DEFAULT FALSE); Below
is my environment that is configured and running in a normal mode. I have my
primary database in San Francisco, and my standby database in New York.
Both databases, Primary and Standby are backing up to the local Recovery
Appliance in their respective same data center. Request Only Mode is
configured between the two Recovery Appliances.
To
demonstrate what happens when a failure occurs, I will assume that the Recovery
Appliance in the SFO datacenter is down for a period of time. In this
scenario, backups can no longer be sent to the SFO Recovery Appliance, but Data
Guard Redo Traffic still occurs to the standby database in New York, and the
standby database in New York is still backing up locally to the Recovery
Appliance in New York.
When
the SFO appliance comes back on-line, it will synchronize the backup
information with that on the NYC Recovery Appliance. The SFO appliance
will request datafile backups and any controlfile backups that are older
than 48 hours, from NYC appliance.
NOTE: The assumption is that a new
backup will occur locally over a faster LAN network and fill any gaps within
the last 48 hours. The backups requested from its pair will be transferred
over a slower WAN and fill any gaps older than 48 hours
If
Real-Time redo is configured, the protected databases will immediately begin
the archived log gap fetch process, and fill any gaps in archive logs on SFO
appliance that are available on the protected databases. The SFO appliance will
also check for new logs to be requested from NYC appliance once per hour over
the next 6 hours. This gives time for local arch log gap fetch to run via LAN,
which is faster than replicating logs via WAN from NYC.
HADR
Bonus Feature: Since the SFO appliance recovery catalog is immediately
synchronized with the NYC recovery catalog, backup pieces on the NYC Recovery
Appliance are available for recovery.
With this capability you have full recovery protection as soon as the
catalog synchronization completes.
This
ensures that the SFO Recovery Appliance will be able to provide a short
Recovery Point Object without waiting for the next backup job to occur.
All
of this happens transparently and quickly returns the Recovery Appliance
to the expected level of protection for the database backups.
For more details on
implementing different replication modes, refer to the Administrator’s Guide.