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
Snapshots and Data Consistency
Replicating iSCSI Configuration
Upgrading From 2009.Q3 and Earlier
Snapshots are the basis for incremental 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 need not 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 we've tried to replicate this action before and whether 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 ZFSSA, particularly as it applies to snapshots.
For information about space management for replicating LUNs, see Space Management for Replicating LUNs