Administrator Guide

Secondary volumes and volume groups
When the replication set is created—either through the CLI or the PowerVault Manager—secondary volumes and volume groups are
created automatically. Secondary volumes and volume groups cannot be mapped, moved, expanded, deleted, or participate in a rollback
operation. Create a snapshot of the secondary volume or volume group and use the snapshot for mapping and accessing data.
Queuing replications
You can specify the action to take when a replication is running and a new replication is requested.
• Discard. Discard the new replication request.
• Queue Latest. Take a snapshot of the primary volume and queue the new replication request. If the queue contained an older
replication request, discard that older request. A maximum of one replication can be queued. This is the default.
NOTE: If the queue policy is set to Queue Latest and a replication is running and another is queued, you cannot change
the queue policy to discard. You must manually remove the queued replication before you can change the policy.
Maintaining replication snapshot history from the
Replications topic
A replication set can be configured to maintain a replication snapshot history. As part of handling a replication, the replication set will
automatically take a snapshot of the primary and/or secondary volume(s), thereby creating a history of data that has been replicated over
time. This feature can be enabled for a secondary volume or for a primary volume and its secondary volume, but not for a volume group.
When this feature is enabled:
• For a primary volume, when a replication starts it will create a snapshot of the data image being replicated.
• For a secondary volume, when a replication successfully completes it will create a snapshot of the data image just transferred to the
secondary volume. (This is in contrast to the primary volume snapshot, which is created before the sync.) If replication does not
complete, a snapshot will not be created.
• You can set the number of snapshots to retain from 1 through 16, referred to as the snapshot retention count. This setting applies to
management of snapshots for both the primary and secondary volume and can be changed at any time. Its value must be greater than
the number of existing snapshots in the replication set, regardless of whether snapshot history is enabled. If you select a snapshot
retention count value that is less than the current number of snapshots, an error message appears. Thus, you must manually delete
the excess snapshots before reducing the snapshot count setting. When the snapshot count is exceeded, the oldest unmapped
snapshot will be discarded automatically.
• The snapshots are named basename_nnnn where _nnnn starts at 0000 and increments for each subsequent snapshot. If primary
volume snapshots are enabled, snapshots with the same name will exist on the primary and secondary systems. The snapshot number
is incremented each time a replication is requested, whether or not the replication completes — for example, if the replication was
queued and subsequently removed from the queue.
• If the replication set is deleted, any existing snapshots automatically created by snapshot history rules will not be deleted. You will be
able to manage those snapshots like any other snapshots.
• Manually creating a snapshot will not increase the snapshot count associated with the snapshot history. Manually created snapshots
are not managed by the snapshot history feature. The snapshot history feature generates a new name for the snapshot that it intends
to create. If a volume of that name already exists, the snapshot history feature will not overwrite that existing volume. Snapshot
numbering will continue to increment, so the next time the snapshot history feature runs, the new snapshot name will not conflict with
that existing volume name.
• The snapshot basename and snapshot retention count settings only take effect when snapshot history is set to secondary or both,
although these settings can be changed at any time.
• A mapped snapshot history snapshot will not be deleted until after it is unmapped.
• A snapshot created by this feature is counted against the system-wide maximum snapshots limit, with the following result:
○ If the snapshot count is reached before the system limit then the snapshot history is unchanged.
○ If the system limit is reached before the snapshot count then the snapshot history stops adding or updating snapshots.
• You can set the retention priority for snapshots to the following. In a snapshot tree, only leaf snapshots can be deleted automatically.
○ never-delete. Snapshots will never be deleted automatically to make space. The oldest snapshot in the snapshot history will be
deleted once the snapshot count has been exceeded. This is the default.
○ high. Snapshots can be deleted after all eligible medium-priority snapshots have been deleted.
○ medium. Snapshots can be deleted after all eligible low-priority snapshots have been deleted.
122
Working in the Replications topic