Replication Actions and Packages

Language:

A replication action specifies where and how to replicate a project or share. Replication actions are created on the source appliance specifying the following:

A replication group that includes either a project or individual shares
Name of the replication target
Name of a storage pool on the replication target (used only during the initial setup)
Frequency (scheduled or continuous) of the update
Number of Auto-Snapshots (Scheduled Snapshots) that are retained on the target
Additional options such as encryption of the data stream or disabling compression

A replication group is specified implicitly by the project or share on which the action is configured (see Replication Storage Pools). The replication target and storage pool cannot be changed after the action is created, but the other options can be modified at any time. If a replication update is in progress when an option is changed, then the new value takes effect when the next update begins (With the exception of the max bandwidth parameter, which takes effect immediately after the modification).

When a replication action is created on the source appliance, a package on the target in the specified storage pool is created. The package on the replication target 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. Actions are the primary unit of replication configuration on the appliance.

Replication Update Frequency

Replications can be executed manually or configured in the replication action to be sent continuously or at scheduled times. The three replication modes are:

Manual - Replication is started manually, at any time, by the administrator. A manual replication update can be useful for testing purposes and for applications that require data to be in a certain state before replication can occur. See Manually Sending a Replication Update BUI, CLI.
Scheduled - Replication is automatically executed according to a selected schedule. The scheduled frequency can be set to replicate to the target every 5, 10, 15, 20 or 30 minutes, every 1, 2, 4, 8 or 12 hours, every day, every week, or every month. More granular update frequencies can be set by defining multiple schedules for a single replication action.

The Auto selection, which is available when creating the first schedule for a replication action, is a start time generated by the appliance. When multiple replication actions are configured on an appliance, the auto-generated start time can minimize overlapping replication updates and improve load balancing.

The scheduled frequency can also be set to replicate to the target based on the automatic snapshot schedules configured in the project or share. When this option is selected, replication updates are performed when the scheduled automatic snapshots are created.
Continuous - Replication is executed continuously. As soon as one replication update is complete, a subsequent update is started. Changes are transmitted as frequently as possible, resulting in sending a constant stream of all filesystem changes to the target system. For filesystems with a lot of churn (many files created and destroyed in short intervals), this can result in replicating much more data than is actually necessary. However, as long as replication can keep up with the data changes, this results in the minimum amount of data lost in the event of a data-loss disaster on the source system.

Replication Action and Package Relationship

A replication action and package are bound to each other. If the package is somehow corrupted or destroyed, the action cannot 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). A warning will occur, in both the BUI and CLI, if you attempt to perform an operation 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, you must sever or destroy the package and action, then create a new action on the source.

Note - The appliance avoids destroying data on the target unless explicitly requested to do so 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 appliance cannot overwrite the previously received data. To resolve this, administrators should destroy the existing action and package, create a new action, then restart replication.

Related Topics