Reverse the Direction of Replication

Language:

The direction of the replication can be reversed to support two-system disaster recovery plans and disk-to-disk backups.

Reversing Replication for Disaster Recovery

The reverse replication operation converts the replication package into a local project. This operation also configures a replication action on the new local project for incremental replication back to the source appliance. The first update attempt will convert the original project on the source system into a replication package and roll back any changes made since the last successful replication update from that system.

The following figure describes a typical reverse replication sequence of events.

Figure 33 Using Remote Replication for Disaster Recovery

image:Diagram showing the stages of reverse replication for disaster recovery.

Legend	Description
1	The production system is the source appliance serving the client workload and replicating to the replication target located at a recovery site. A complete failure of the source appliance occurs at the production site. 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 original relationship between the source appliance at the production site and the replication target at the recovery site is restored.

Share-level and Project-level Reversal

When the original source project is converted into a replication package on the original source appliance (which is 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.

Before reversing the direction of replication for a package, stop replication updates of that project from the source appliance. 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 replication target (now source appliance).

If a replication update is performed during or after a reversal operation, the update fails with an appropriate alert. The replication action is then disabled, resulting in no future updates from this action to the replication target. A new replication action and a full update are required to send updates from the original project to a new replication package.

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