Provides options to recover a replication set after a disaster. All options work with either a single volume or a volume group. First you run the command to perform a failover operation. After this operation completes, you rerun the command to perform one of the following recovery operations: failback-no-restore, or reverse.
CAUTION: The
failback-restore and
reverse operations are designed to discard the latest updates to the primary volume since the last successful replication and replace it with the secondary volume which has been updating while in failover state. To mitigate potential problems, take snapshots of both the primary and secondary volumes before performing this recovery operation.
Performing a failover operation
Run this operation on the secondary system to move the replication set into "failed over" state. In this state, all scheduled or current replications of the replication set will cease and the secondary volume can be mapped and accessed for use (including rollback to the contents of any manually created or snapshot-history snapshot). Before performing
failover, create a snapshot of the secondary volume to preserve the contents of the last replication, if snapshot history was not enabled.
Performing a failback-restore operation
This is a two-step operation that can restore the primary system using updates made to the secondary volume while the replication set was failed over to the secondary system.
First, run this operation on the secondary system. This will unmap the primary volume and the secondary volume and put the replication set in a temporary "failback-restore" state that permits a replication to go in the opposite direction: from the secondary volume to the primary volumes. Once the direction has been temporarily reversed, data from the secondary volume is replicated to the primary volume. At this point, data has been restored from the secondary system, but the replication set remains in a temporary state. Host mappings to either primary or secondary volumes are blocked when in this state. Replication snapshot history is suppressed while a
failback-restore operation is in progress.
Second, run this operation on the primary system. This will reverse replication back to the normal direction: from the primary volume to the secondary volume. The temporary state imposed by the first step will be removed and the replication set will return to normal operation.
Performing a failback-no-restore operation
This restores the replication set to functioning as it did before the
failover operation was performed. If the secondary volume was mapped while in "failed over" state, it will be unmapped. The direction of replication will not be changed from the original configuration and it will not automatically start a replication. After this operation completes, any updates to the secondary volume will remain. However, updates to the secondary volume will be discarded when the next replication request is completed.
Performing a reverse operation
This allows the replication set to return to normal operation, but with the replication roles reversed: the original primary volume becomes the secondary volume and the original secondary volume becomes the primary volume. The original primary volume becomes unmapped. The operation preserves any updates that may have been done to the original secondary volume while it was in "failed over" state, but does not automatically move these updates to the original primary volume. The next replication run will move these updates from the new primary volume to the new secondary volume, and will delete any changes made to the secondary (original primary) since the last replication.
|