Chapter 1 Oracle ZFS Storage Appliance Overview
Chapter 3 Initial Configuration
Chapter 4 Network Configuration
Chapter 5 Storage Configuration
Chapter 6 Storage Area Network Configuration
Chapter 8 Setting ZFSSA Preferences
Chapter 10 Cluster Configuration
Chapter 12 Shares, Projects, and Schema
Project Replication Actions and Packages
Project Replication Storage Pools
Project-level vs. Share-level Replication
Configuring Project Replication
Creating and Editing Targets in the BUI
Creating and Editing Targets in the CLI
Creating and Editing Actions in the BUI
Creating and Editing Actions in the CLI
Replication Modes: Scheduled or Continuous
Replication - Including Intermediate Snapshots
Replication - Sending and Canceling Updates
Managing Replication Packages in the BUI
Managing Replication Packages in the CLI
Cloning a Package or Individual Shares
Exporting Replicated Filesystems
Reversing the Direction of Replication
Destroying a Replication Package
Reversing Replication - Establish Replication
Reversing Replication - Simulate Recovery from a Disaster
Reversing Replication - Resume Replication from Production System
Forcing Replication to use a Static Route
Force Replication to use a Static Route
Cloning a Received Replication Project
Replicating iSCSI Configuration
Upgrading From 2009.Q3 and Earlier
The ZFSSA replicates snapshots and each snapshot is received atomically on the target, so the contents of a share's replica on the target always matches the share's contents on the source at the time the snapshot was taken. Because the snapshots for all shares sent in a particular group are taken at the same time (see above), the entire package contents after the completion of a successful replication update exactly matches the group's content when the snapshot was created on the source (when the replication update began).
However, each share's snapshots are replicated separately (and serially), so it's 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 (after some shares have been updated but before others have) and after a failed replication update (after which some shares may have been updated but others may not have been).
To summarize:
Each share is always point-in-time consistent on the target (self-consistent).
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 (package-consistent).
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.