Remote Replication Concepts
Legend Description
From the recovery site, the administrator reverses the direction of replication. This operation converts the
replication package to a local, writable project.
The administrator redirects client workloads and failover IP addresses to the recovery site.
2 After the production site is restored and back to normal operations, the administrator initiates a replication update
from the recovery site to the production site. This operation converts the production copy into a replication
package, and rolls back any changes written to the recovery site while the production site was down.
3 Once the production site is updated, the administrator reverses the direction of replication again, which makes the
copy at the production site writable.
The administrator then redirects client workloads and failover IP address back to the production site.
The originial relationship between the source appliance at the production site and the target appliance at the
recovery site is restored.
As part of the conversion of the original source project into a replication package on the original
source system (now acting as the target), the shares that were replicated as part of the action/
package currently being reversed are moved into a new replication package and unexported.
The original project remains in the local collection, but may end up empty if the action/package
included all of its shares. When share-level replication is reversed, any other shares in the
original project remain unchanged.
After establishing share-level replication from one appliance to another, reversing that
replication on the target appliance destroys the replication schedule. A replication action is then
created at the project level which contains the correct target appliance without a schedule.
When reversing the direction of replication for a package, it is strongly recommended that
administrators first stop replication of that project from the source. If a replication update is in
progress when an administrator reverses the direction of replication for a project, administrators
cannot know which consistent replication snapshot was used to create the resulting project on
the former target appliance (now source appliance).
Because all local shares are exported, all shares in a package are exported when the package
is reversed, whether or not they were previously exported. If there are mount point conflicts
between replicated filesystems and other filesystems on the system, the reverse operation will
fail. These conflicts must be resolved before severing by reconfiguring the mount points of
the relevant shares. Because this operation is typically part of the critical path of restoring
production service, it is strongly recommended to resolve these mount point conflicts when the
systems are first set up rather than at the time of disaster recovery failover.
Related Topics
■
“Setting Up Remote Replication for Disaster Recovery (BUI)” on page 517
■
“Setting Up Remote Replication for Disaster Recovery (CLI)” on page 520
■
Using Remote Replication for Disk-to-Disk Backup
556 Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016
To Next Page
Loading...
Need help?
General
