Managing replication for disaster recovery

You can manage replication for disaster recovery by using the management GUI, CLI, or REST API.

When a replication policy for disaster recovery is assigned to a volume group, the volume group operates in one of three modes:

Production: The volumes in a production volume group are accessible for host I/O and configuration changes are allowed to the volume group. This system acts as the source for replication to the target volumes on the recovery system. The production volume group contains the most up-to-date copy of data for host access.
Recovery: The volumes in a recovery volume group are the target for replication. Read-only access from a host is permitted if the volume group has a valid recovery point and is replicated using a disaster recovery replication policy (used with volume groups that are in a storage partition), otherwise the volumes are inaccessible for host I/O; starting a recovery test or enabling independent access to a volume group will transition the volumes into an online and read-writeable state. While a volume is in a read-only state it is not guaranteed to be completely consistent at all times as the data will be changing as writes are replicated from the production copy, but it is sufficient for discovering the filesystem and mounting to a server. Configuration changes are not allowed on the recovery copy, but changes made to the production copy are copied to the recovery copy.
Independent: If access is enabled for the recovery copy of a volume group, such as during a disaster, each copy of the volume group is independently accessible for I/O and configuration changes are allowed on both. Replication is suspended in this state. While independent, any data or configuration changes that are made on either system are not copied to the other system. When replication is restarted, the system automatically updates the data and the configuration on the recovery volume group to match the production volume group.

Replication policies do not define a direction for replication. The initial direction of replication is determined when a replication policy is associated with a volume group or a volume group is created specifying a replication policy. The system where the replication policy is assigned starts as the production system.

Removing a replication policy from the production copy of a volume group causes the recovery volume group and its volumes to be deleted. Independent access must be enabled on the recovery copy first to keep the copy, and the replication policy can then be removed from the volume group without affecting the other copy.

The replication policy assigned to a volume group can be replaced with a different replication policy without requiring any resynchronization, for example, to use a policy with a different recovery point objective alert for the volume group. The new policy must specify the same systems in the same locations.

Managing and monitoring disaster recovery for a volume group

Using the management GUI

To configure disaster recovery, assign a replication policy to the volume group. Using the management GUI, navigate to the Volume groups page and select the desired volume group, then select the Policies tab. When a replication policy is assigned to the volume group, this page is used for managing and monitoring replication.

Using the command-line interface

To assign a replication policy to a volume group using the CLI, use the following command:

chvolumegroup -replicationpolicy <policy> <volumegroup>

To unassign a replication policy from a volume group, use the following command:

chvolumegroup -noreplicationpolicy <volumegroup>

To view a list of all the volume groups that are configured for replication, use the following command:

lsvolumegroupreplication

To view the detailed status of replication for an individual volume group, use the following command:

lsvolumegroupreplication <volumegroup>

Accessing the recovery copy of a volume group

Using the management GUI

Log in to the system with the recovery copy.
Navigate to the Volume groups page and select the desired volume group.
Select the Policies tab and review the recovery point for the copy.
If the recovery point is acceptable, click Enable access to enable independent access to the volume group.
If the production system is inaccessible, the production copy is made independent when connectivity is restored. The recovery copy will always become independent and available for use immediately.

Using the command-line interface

You can use the chvolumegroupreplication command to enable independent access when logged in to the system with the recovery copy:

chvolumegroupreplication -mode independent <volumegroup>

Restarting replication from the independent state

When the replication mode for a volume group is in the independent state, replication can be restarted in either direction.

The replication policy assigned to the volume group on the system you want to use as the production copy will be used to define the replication requirements, such as the RPO alert for the group. If the volume group was previously the recovery copy in a storage partition, it might not yet have a replication policy assigned. You must assign a replication policy to the volume group before you can restart replication from this system. If you use the management GUI to restart replication, the GUI guides you through the required steps to create a new replication policy or select an existing policy to assign to the volume group as part of the restart task.

Using the management GUI

Log in to the system with the volume group you want to use as the new production copy.
Navigate to the Volume groups page and select the desired volume group.
Select the Policies tab.
Click the Restart replication action to restart replication using the volume group on the local system as the production copy. Any changes made to the copy on the remote system will be overwritten when replication is restarted.

Using the command-line interface

You can use the chvolumegroupreplication command to restart replication when logged in to the system with the copy you want to use as the production copy:

chvolumegroupreplication -mode production <volumegroup>