startrcconsistgrp

Syntax

Parameters

-primary master | aux: (Optional) Specifies the copy direction by defining whether the master or auxiliary disk becomes the primary (source). This parameter is required when the primary is undefined if, for example, the consistency group is in the Idling state.
-force: (Optional) Specifies that you want the system to process the copy operation even if it might lead to a temporary loss of consistency while synchronization occurs. This parameter is required if the consistency group is in the ConsistentStopped state, but is not synchronized or is in the idling state - except if consistency protection is configured.
-clean: (Optional) Specifies that the volume indicated as secondary is clean for each of the relationships that belong to the group. Any changes that are made on the secondary volume are ignored, and only changes made on the clean primary volume are considered during synchronization of the primary and secondary disks. The consistency group must be in an Idling (connected) state for this parameter to work.
Attention: Specify this parameter when all data changed on the secondary volumes while the consistency group was in the idling state matches the state of the primary volumes when the consistency group was stopped. Otherwise, relationships that are not consistent are reported as consistent. Once this has been done, there is no method to determine whether these volumes ever reach a true consistent state until a full background copy can be carried out again.
rc_consist_group_id | rc_consist_group_name: (Required) Specifies the ID or name of the consistency group to start.

Description

You cannot use this command to start a remote copy relationship if the primary volume is a target volume of a prepared FlashCopy® mapping.

This command can be issued only to a consistency group that is connected. For a consistency group that is idling, this command assigns a copy direction (primary and secondary roles) and begins the copy process. Otherwise, this command restarts a previous copy process that was stopped either by a stop command or by an I/O error.

Note: You cannot start a consistency group if it contains a relationship with primary and secondary volumes that are different sizes.

If you specify stoprcconsistgrp -access on an existing remote copy relationship that is restarted and the resultant secondary volume (depending on the choice of primary) is mapped to a host of type hide_secondary, that volume is not presented to the host. This is true even though it is mapped for configuration purposes. The mapped volumes are presented to the host if the:

Host type is changed to a type other than hide_secondary
Remote copy relationship is stopped and you specify stoprcconsistgrp -access
Volume ceases to be a secondary volume because the remote copy relationship is being deleted or switched

If the resumption of the copy process leads to a period when the relationship is not consistent, then you must specify the -force parameter when you restart the relationship. This situation can arise if the relationship is stopped and then further input transactions is performed on the original primary disk of the relationship. When you use the -force parameter in this situation, the data on the secondary disk is not usable (because it is inconsistent) in a disaster recovery circumstance.

In the idling state, you must provide the -primary parameter. In other connected states, you can provide the -primary parameter, but it must match the existing setting.

The -force parameter is required if consistency would be lost by starting a copy operation. This can occur if write operations on either primary or secondary volumes take place since the ConsistentStopped or idling state occurred. If the command is issued without the -force parameter in such circumstances, the command fails . In general, the -force parameter is required if the group is in one of the following states:

consistent_stopped but not synchronized (sync=out_of_sync)
i but not synchronized (sync=out_of_sync)

The -force parameter is not required if the group is in inconsistent_stopped, inconsistent_copying, or consistent_synchronized state. The command does not fail if you specify the -force parameter.

When you configure a secondary change volume on all relationships in a consistency group, the consistency group changes to consistent_copying state during resynchronization. If you specify startrcconsistgrp for a consistency group that is in an idling state, consistency protection is disabled if any of the secondary volumes are written to. This means that you must specify the -force parameter.

The -clean parameter can be used in the following scenario:

You specify the -sync parameter to create a consistency group. It does not matter if the primary and secondary contain the same data - even though the use of the -sync parameter implies that is true.
You specify stoprcconsistgrp -access. This permits access to the secondary disk. Change recording begins at the primary.
You copy and load an image of the primary disk onto to the secondary disk. It is permissible to allow updates to the primary disk during the image copy as this image can be only a fuzzy image of the primary disk.
You specify the startrcconsistgrp command with the -primary master, -force, and -clean parameters. The auxiliary disk is marked as clean and changes on the master disk that occur since the relationship was stopped are copied to the auxiliary disk.
A background copy completes and the relationships in the group become consistent and synchronized.

After you restart a consistency group in either of these states (Idling or multi), the data on the secondary volumes is not usable for disaster recovery until the consistency group becomes consistent.

A Global Mirror consistency group with a cycling_mode of multi in either of these states does not require the -force parameter because consistent secondary images are retained. However, if such a consistency group is in idling state and written data is received at any secondary volume in the consistency group, the -force flag is still required, because the secondary volumes have a divergent image that cannot represent a consistent earlier state.

A Global Mirror relationship with a cycling mode of:

none uses the non-cycling Global Mirror algorithm
multi must have a change volume that is configured at the primary volume (or the command fails)
multi must also have a change volume that is configured at the secondary volume (or the command fails)
multi performs multiple cycles of cycling

After you create a background copy the relationship remains in copying state, waiting for the remainder of the period time to expire before you perform a new cycle. If the secondary change volume is deconfigured when the background copy completes, the relationship stops as if there is no cycle period.

An invocation example

startrcconsistgrp rccopy1

The resulting output:

No feedback