Replication Snapshot Management - Oracle ZFS Storage Appliance Administration Manual

However, each share's snapshots are replicated separately, so it is possible for some shares
within a package to have been updated with a snapshot that is more recent than those of other
shares in the same package. This is true during a replication update and after a failed replication
update.
To summarize:
Each share is always point-in-time consistent on the target.
■
When no replication update is in progress and the previous replication update succeeded,
■
each package's shares are also point-in-time consistent with each other.
When a replication update is in progress or the previous update failed, package shares
■
may be inconsistent with each other, but each one will still be self-consistent. If package
consistency is important for an application, one must clone the replication package, which
always clones the most recent successfully received snapshot of each share.
Related Topics
"Replication Snapshot Management" on page 543
■

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:
Remote Replication Concepts
Remote Replication 543