Project Replication Actions and Packages

Targets represent a connection between ZFSSAs that enables them to communicate securely for the purpose of replication, but targets do not specify what will be replicated, how often, or with what options. For this, administrators must define replication actions on the source ZFSSA. Actions are the primary administrative control point for replication, each one specifying:

• a replication group (a project and some number of shares)

• a target ZFSSA

• a storage pool on the target ZFSSA (used only during the initial setup)

• a frequency (which may be manual, scheduled, or continuous)

• additional options such as whether to encrypt the data stream on the wire

The group is specified implicitly by the project or share on which the action is configured (see Project-level vs. Share-level Replication ). The target ZFSSA and storage pool cannot be changed after the action is created, but the other options can be modified at any time. Generally, if a replication update is in progress when an option is changed, then the new value only takes effect when the next update begins.

Actions are the primary unit of replication configuration on the ZFSSA. Each action corresponds to a package on the target ZFSSA that contains an exact copy of the source project and shares on which the action is configured as of the start time of the last replication update. Administrators configure the frequency and other options for replication updates by modifying properties of the corresponding action. Creating the action on the source ZFSSA creates the package on the target ZFSSA in the specified storage pool, so the source must be able to contact the target when the action is initially created.

The first update for each replication action sends a full sync (or full update): the entire contents of the action's project and shares are sent to the target ZFSSA. Once this initial sync completes, subsequent replication updates are incremental: only the changes since the previous update are sent. The action (on the source) and package (on the target) keep track of which changes have been replicated to the target through named replication snapshots. Generally, as long as at least one full sync has been sent for an action and the action/package connection has not been corrupted due to a software failure or administrative action, replication updates will be incremental.

The action and package are bound to each other. If the package is somehow corrupted or destroyed, the action will not be able to send replication updates, even if the target still has the data and snapshots associated with the action. Similarly, if the action is destroyed, the package will be unable to receive new replication updates (even if the source still has the same data and snapshots). The BUI and CLI warn administrators attempting to perform operations that would destroy the action-package connection. If an error or explicit administrative operation breaks the action-package connection such that an incremental update is no longer possible, administrators must sever or destroy the package and action and create a new action on the source.

NOTE: The ZFSSA avoids destroying data on the target unless explicitly requested by the administrator. As a result, if the initial replication update for an action fails after replicating some of the data and leaving incomplete data inside the package, subsequent replication updates using the same action will fail because the ZFSSA cannot overwrite the previously received data. To resolve this, administrators should destroy the existing action and package and create a new action and package and start replication again.

In software releases prior to 2010.Q1, action and replica configuration (like target configuration) was stored on the controller rather than as part of the project and share configuration in the storage pool. As a result, a factory reset caused configuration to be destroyed. In 2010.Q1 and later releases, the action and package configuration is stored in the storage pool with the corresponding projects and shares and will be available even after a factory reset. However, target information will still be lost, and actions with missing targets currently cannot be configured to point to a new target.