Remote Replication Concepts
■
During the first replication update and after the initial update when replication is not active,
there is exactly one project-level snapshot for each action configured on the project or any
share in the group. A replication action may create snapshots on shares that are in the same
project as the share(s) in the group being replicated by the action, but that are not being sent
as part of the update for the group.
■
During subsequent replication updates of a particular action, there may be two project-
level snapshots associated with the action. Both snapshots may remain after the update
completes in the event of failure where the source was unable to determine whether the
target successfully received the new snapshot (as in the case of a network outage during the
update that causes a failure).
■
None of the snapshots associated with a replication action can be destroyed by the
administrator without breaking incremental replication. The system will not allow
administrators to destroy snapshots on either the source or target that are necessary for
incremental replication. To destroy such snapshots on the source, one must destroy the
action (which destroys the snapshots associated with the action). To destroy such snapshots
on the target, one must first sever the package (which destroys the ability to receive
incremental updates to that package).
■
Administrators must not rollback to snapshots created prior to any replication snapshots.
Doing so will destroy the later replication snapshots and break incremental replication for
any actions using those snapshots.
■
Replication's usage of snapshots requires that administrators using replication understand
space management on the appliance, particularly as it applies to snapshots.
Related Topics
■
“Space Management for Shares” on page 396
■
Using Remote Replication for Disk-to-Disk Backup
iSCSI Configurations and Replication
Replication updates include most of the configuration specified on the Shares screen for a
project and its shares. This includes any target groups and initiator groups associated with
replicated LUNs.
When using non-default target groups and initiator groups, administrators must ensure that the
target groups and initiator groups used by LUNs within the project also exist on the replication
target. If the target group or initiator group does not exist on the target system, a clone, sever, or
reverse replication will fail. An error message reports that the initiator or target group name was
either deleted or renamed on the target system.
The SCSI GUID associated with a LUN is replicated with the LUN. As a result, the LUN on
the target appliance will have the same SCSI GUID as the LUN on the source appliance. Clones
544 Oracle ZFS Storage Appliance Administration Guide, Release OS8.6.x • September 2016
To Next Page
Loading...
Need help?
General
