Oracle ZFS Storage Appliances support snapshot-based replication of projects and shares from a source ZFSSA to any number of target ZFSSAs manually, on a schedule, or continuously. The replication includes both data and metadata. Remote replication (or just "replication") is a general-purpose feature optimized for the following use cases:
Disaster recovery. Replication can be used to mirror an ZFSSA for disaster recovery. In the event of a disaster that impacts service of the primary ZFSSA (or even an entire data center), administrators activate service at the disaster recovery site, which takes over using the most recently replicated data. When the primary site has been restored, data changed while the disaster recovery site was in service can be migrated back to the primary site and normal service restored. Such scenarios are fully testable before such a disaster occurs.
Data distribution. Replication can be used to distribute data (such as virtual machine images or media) to remote systems across the world in situations where clients of the target ZFSSA wouldn't ordinarily be able to reach the source ZFSSA directly, or such a setup would have prohibitively high latency. One example uses this scheme for local caching to improve latency of read-only data (like documents).
Disk-to-disk backup. Replication can be used as a backup solution for environments in which tape backups are not feasible. Tape backup might not be feasible, for example, because the available bandwidth is insufficient or because the latency for recovery is too high.
Data migration. Replication can be used to migrate data and configuration between ZFSSAs when upgrading hardware or rebalancing storage. Shadow migration can also be used for this purpose.
The remote replication feature has several important properties:
Snapshot-based. The replication subsystem takes a snapshot as part of each update operation. For a full update, the entire project contents up to the snapshot are sent. For an incremental update, only the changes since the last replication snapshot for the same action are sent.
Block-level. Each update operation traverses the filesystem at the block level and sends the appropriate filesystem data and metadata to the target.
Asynchronous. Because replication takes snapshots and then sends them, data is necessarily committed to stable storage before replication even begins sending it. Continuous replication effectively sends continuous streams of filesystem changes, but it's still asynchronous with respect to NAS and SAN clients.
Includes metadata. The underlying replication stream serializes both user data and ZFS metadata, including most properties configured on the Shares screen. These properties can be modified on the target after the first replication update completes, though not all take effect until the replication connection is severed. For example, this allows sharing over NFS to a different set of hosts than on the source. See Managing Replication Packages for details.
Secure. The replication control protocol used among ZFS Storage Appliances is secured with SSL. Data can optionally be protected with SSL as well. Appliances can only replicate to/from other ZFSSAs after an initial manual authentication process, see Creating and Editing Targets.
Replication has the following known limitations:
Changing a target's IP address will break the replication
Actions cannot move between pools
I/O is limited to a maximum of 200 MB/s per project level replication