JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle® ZFS Storage Appliance Administration Guide
Oracle Technology Network
Print View
search filter icon
search icon

Document Information

Using This Documentation

Chapter 1 Oracle ZFS Storage Appliance Overview

Chapter 2 Status

Chapter 3 Initial Configuration

Chapter 4 Network Configuration

Chapter 5 Storage Configuration

Chapter 6 Storage Area Network Configuration

Chapter 7 User Configuration

Chapter 8 Setting ZFSSA Preferences

Chapter 9 Alert Configuration

Chapter 10 Cluster Configuration

Chapter 11 ZFSSA Services

Chapter 12 Shares, Projects, and Schema

Chapter 13 Replication

Replication Overview

Understanding Replication

Replication Terminology

Project Replication Targets

Project Replication Actions and Packages

Project Replication Storage Pools

Project-level vs. Share-level Replication

Configuring Project Replication

Creating and Editing Targets

Creating and Editing Targets in the BUI

Creating and Editing Targets in the CLI

Creating and Editing Actions

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

Managing Replication Packages in the BUI

Managing Replication Packages in the CLI

Canceling Replication Updates

Disabling a Package

Cloning a Package or Individual Shares

Exporting Replicated Filesystems

Severing Replication

Reversing the Direction of Replication

Destroying a Replication Package

Replication Tasks

Reversing Replication - Establish Replication

Reverse Replication

Reversing Replication - Simulate Recovery from a Disaster

Reverse Replication

Reversing Replication - Resume Replication from Production System

Reverse Replication

Forcing Replication to use a Static Route

Force Replication to use a Static Route

Cloning a Received Replication Project

Remote Replication Details



Replication Audit Events

Replication and Clustering

Snapshots and Data Consistency

Snapshot Management

Replicating iSCSI Configuration

Replicating Clones

Observing Replication

Replication Failures

Replication Compatibility

Upgrading From 2009.Q3 and Earlier

Chapter 14 Shadow Migration

Chapter 15 CLI Scripting

Chapter 16 Maintenance Workflows

Chapter 17 Integration


Project Replication Actions and Packages

Targets represent a connection between ZFSSAs that enables them to communicate securely for the purpose of replication, but targets do not specify what will be replicated, how often, or with what options. For this, administrators must define replication actions on the source ZFSSA. Actions are the primary administrative control point for replication, each one specifying:

The group is specified implicitly by the project or share on which the action is configured (see Project-level vs. Share-level Replication ). The target ZFSSA and storage pool cannot be changed after the action is created, but the other options can be modified at any time. Generally, if a replication update is in progress when an option is changed, then the new value only takes effect when the next update begins.

Actions are the primary unit of replication configuration on the ZFSSA. Each action corresponds to a package on the target ZFSSA that contains an exact copy of the source project and shares on which the action is configured as of the start time of the last replication update. Administrators configure the frequency and other options for replication updates by modifying properties of the corresponding action. Creating the action on the source ZFSSA creates the package on the target ZFSSA in the specified storage pool, so the source must be able to contact the target when the action is initially created.

The first update for each replication action sends a full sync (or full update): the entire contents of the action's project and shares are sent to the target ZFSSA. Once this initial sync completes, subsequent replication updates are incremental: only the changes since the previous update are sent. The action (on the source) and package (on the target) keep track of which changes have been replicated to the target through named replication snapshots. Generally, as long as at least one full sync has been sent for an action and the action/package connection has not been corrupted due to a software failure or administrative action, replication updates will be incremental.

The action and package are bound to each other. If the package is somehow corrupted or destroyed, the action will not be able to send replication updates, even if the target still has the data and snapshots associated with the action. Similarly, if the action is destroyed, the package will be unable to receive new replication updates (even if the source still has the same data and snapshots). The BUI and CLI warn administrators attempting to perform operations that would destroy the action-package connection. If an error or explicit administrative operation breaks the action-package connection such that an incremental update is no longer possible, administrators must sever or destroy the package and action and create a new action on the source.

NOTE: The ZFSSA avoids destroying data on the target unless explicitly requested by the administrator. As a result, if the initial replication update for an action fails after replicating some of the data and leaving incomplete data inside the package, subsequent replication updates using the same action will fail because the ZFSSA cannot overwrite the previously received data. To resolve this, administrators should destroy the existing action and package and create a new action and package and start replication again.

In software releases prior to 2010.Q1, action and replica configuration (like target configuration) was stored on the controller rather than as part of the project and share configuration in the storage pool. As a result, a factory reset caused configuration to be destroyed. In 2010.Q1 and later releases, the action and package configuration is stored in the storage pool with the corresponding projects and shares and will be available even after a factory reset. However, target information will still be lost, and actions with missing targets currently cannot be configured to point to a new target.