Oracle^® ZFS Storage Appliance Administration Guide, Release OS8.7.x

Replication Snapshot Management

Snapshots are the basis for replication. The source and target must always share a common snapshot in order to continue replicating incrementally, and the source must know which is the most recent snapshot that the target has. To facilitate this, the replication subsystem creates and manages its own snapshots. Administrators generally do not need to be concerned with them, but the details are described here since snapshots can have significant effects on storage utilization.

Each replication update for a particular action consists of the following steps:

• Determine whether this is an incremental or full update based on whether:

  • An attempt was made to replicate this action before and

  • The target already has the necessary snapshot for an incremental update

• Take a new project-level snapshot.

• Send the update. For a full update, send the entire group's contents up to the new snapshot. For an incremental update, send the difference between from the previous (base) snapshot and the new snapshot.

• Record the new snapshot as the base snapshot for the next update and destroy the previous base snapshot (for incremental updates). The base snapshot remains on the target until the next update is received at which point it is the first thing that is destroyed.

This has several consequences for snapshot management:

• 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.

Intermediate Replication Snapshots

A replication action can be set to include non-replication snapshots. When the property "Include Snapshots" is set, replication updates include the non-replication snapshots created after the previous replication update (or since the share's creation, in the case of the first full update). This includes automatic snapshots and administrator-created snapshots. This property can be disabled to skip these snapshots and send only the changes between replication snapshots with each update.

The action property include_snaps should be enabled in order to replicate any intermediate snapshots, including auto snapshots.

Related Topics

• Space Management for Shares

• Managing User-Generated Snapshots

Replication Automatic Snapshot Management

The automatic scheduled snapshots feature allows for automatically creating and destroying snapshots for projects and/or shares based on administrator-provided schedules. The schedule specifies when to create an automatic snapshot, and how many snapshots to retain. Several schedules can be created for a project or a share.

With Remote Replication, snapshots, including automatic snapshots, can be included in replication updates and will be available on the replication target as part of the corresponding replication package.

By default, the number of automatic snapshots retained on the target corresponds to the retention setting (Keep At Most) in the project's or share's snapshot schedule.

Replication actions can be configured to retain a separate, specific number of automatic snapshots on the target throughout replication updates.

Reverse Replication and Automatic Snapshot Management

When reversing replication, automatic snapshot retention settings are preserved: The source and target will continue to maintain their retention settings.

Example:

• Source A has configured automatic snapshots and retains 5 snapshots on Source A.

• Through a replication action on Source A, Target B has been configured to retain 10 automatic snapshots.

After reverse replication, the source and target have switched to Source B and Target A.

• Now Source B has the automatic snapshot schedule, still retaining 10 snapshots.

• Target A is still configured to retain 5 snapshots. This retention setting is now configurable through the replication action on Source B.

Performing another reverse replication will revert the source and target to their original configurations.

For more information on configuring automatic snapshot retention on a target, see:

• Configuring Automatic Snapshot Retention on a Target (BUI)

• Configuring Automatic Snapshot Retention on a Target (CLI)