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
Before a source ZFSSA can replicate to a target, the two systems must set up a replication peer connection that enables the ZFSSAs to identify each other securely for future communications. Administrators set up this connection by creating a new replication target on the Configuration > Services > Remote Replication screen on the source ZFSSA. To create a new target, administrators specify three fields:
Name (used only to identify the target in the source ZFSSA's BUI and CLI)
Network address or hostname (to contact the target ZFSSA)
Target ZFSSA's root password (to authorize the administrator to set up the connection on the target ZFSSA)
The ZFSSAs then exchange keys used to securely identify each other in subsequent communications. These keys are stored persistently as part of the ZFSSA's configuration and persist across reboots and upgrades. They will be lost if the ZFSSA is factory reset or reinstalled. The root password is never stored persistently, so changing the root password on either ZFSSA does not require any changes to the replication configuration. The password is never transmitted in the clear because this initial identity exchange (like all replication control operations) is protected with SSL.
By default, the replication target connection is not bidirectional. If an administrator configures replication from a source A to a target B, B cannot automatically use A as a target. However, the system supports reversing the direction of replication, which automatically creates a target for A on B (if it does not already exist) so that B can replicate back to A.
NOTE: When a replication source uses NIS or LDAP services to map users or user groups and those users or user groups are included in a share configuration on the source (for example in 'Share Level ACL' or 'Share Space Usage'), those users or user groups should be available on the replication target (for example by using the same NIS or LDAP servers) otherwise replication sever/reverse operations may fail.
To configure replication targets, see Configuring Project Replication .