A clone of a replicated package is a local, mutable project that can be managed like any other project on the system. When the clone project is created, the most recently received snapshot of the replicated shares is used to create the shares within the clone project. These clones share storage with their origin snapshots the same way that clones of share snapshots do (see Cloning a Snapshot BUI, CLI). This mechanism can be used to failover in the case of a catastrophic problem at the replication source, or simply to provide a local version of the data that can be modified.
As long as a clone exists, its origin snapshot cannot be destroyed. When destroying the snapshot (possibly as a result of destroying the share, project, or replication package of which the snapshot is a member), the system warns administrators of any dependent clones that will be destroyed by the operation. Note that snapshots can also be destroyed on the source at any time and such snapshots are destroyed on the target as part of the subsequent replication update. If such a snapshot has clones, the snapshot will not be destroyed until the last clone has been destroyed.
Replicating Clones
When replicating clones, it is important to understand the relationship between a clone replica and its origin snapshot. By default, the replica of a clone maintains its relationship with its origin snapshot, mandating that a replica of the origin snapshot also exist on the target. A replica of a clone origin snapshot must reside in the same pool as the clone, but does not have to be in the same project.
To maintain the relationship between a replicated clone and its origin snapshot, the origin snapshot must be:
Replicated to the target before the initial replication of the clone or
Replicated as part of the same update.
This restriction is not enforced by the appliance software, but must be followed to ensure a successful replication update.
There are several ways to ensure successful replication of a clone so it maintains its relationship with its origin snapshot:
If the clone's origin snapshot is in the same project, use project-level replication.
If the share containing the clone origin snapshot is not in the same project or if the clone or its origin share have been omitted from project-level replication, replicate the origin share first and then replicate the clone using project-level or share-level replication.
On the target system, do not destroy the origin of the clone unless you also intend to destroy the clone itself.
To ensure that the origin snapshot is sent to the target, always set the property "Include snapshots" for the origin's replication action.
Just as a clone and its origin snapshot conserve space on the source appliance, a replicated clone and its replicated origin snapshot conserve space on the replication target. If space conservation on the replication target is less important, the administrator may set the property Include clone origin as data. When this property is set, and the origin snapshot of a clone is not replicated in the same update as the clone, the source appliance inserts a copy of the clone origin's data content into the replica clone. Thus, there is no need to replicate the clone origin share first, but the copy of the clone origin data consumes additional storage space on the target.
When Include snapshots and Include clone origin as data are both set, the replica clone contains only the snapshots that are present in the clone on the source. The source appliance inserts the clone origin data content, not the clone origin snapshots, into the replica clone. This ensures that the snapshots present in the replica clone match the snapshots present in the clone on the source.
The property Include clone origin as data does not affect the replication of a clone and its origin snapshot when they are both replicated in the same update. When replicated together by the same replication action, the relationship between the clone and its origin snapshot is preserved and the space sharing benefit is retained on the target.
Related Topics