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


Replication Failures

Individual replication updates can fail for a number of reasons. Where possible, the ZFSSA reports the reason for the failure in alerts posted on the source ZFSSA or target ZFSSA, or on the Replication screen for the action that failed. You may be able to get details on the failure by clicking the orange alert icon representing the action's status. The following are the most common types of failures:

The replication update was cancelled by an administrator. Replication can be cancelled on the source or target and it's possible for one peer not to realize that the other peer has cancelled the operation.
Network connectivity failure
The ZFSSA was unable to connect to the target ZFSSA due to a network problem. There may be a misconfiguration on the source, target, or the network.
Peer verification failed
The ZFSSA failed to verify the identity of the target. This occurs most commonly when the target has been reinstalled or factory reset. A new replication target must be configured on the source ZFSSA for a target which has been reinstalled or factory reset in order to generate a new set of authentication keys. See Project Replication Targets .
Peer RPC failed
A remote procedure call failed on the target system. This occurs most commonly when the target ZFSSA is running incompatible software. For details, see Upgrading From 2009.Q3 and Earlier .
No package
Replication failed because no package exists on the target to contain the replicated data. Since the package is created when configuring the action, this error typically happens after an administrator has destroyed the package on the target. It's also possible to see this error if the storage pool containing the package is not imported on the target system, which may occur if the pool is faulted or if storage or networking has been reconfigured on the target ZFSSA.
Non-empty package exists
Replication failed because the target package contains data from a previous, failed replication update. This error occurs when attempting to send a replication update for an action whose first replication update failed after replicating some data. The target ZFSSA will not destroy data without explicit administrative direction, so it will not overwrite the partially received data. The administrator should remove the existing action and package and create a new action on the source and start replication again.
Replication failed because it is disabled on the target. Either the replication service is disabled on the target or replication has been disabled for the specific package being replicated.
Target busy
Replication failed because the target system has reached the maximum number of concurrent replication updates. The system limits the maximum number of ongoing replication operations to avoid resource exhaustion. When this limit is reached, subsequent attempts to receive updates will fail with this error, while subsequent attempts to send updates will queue up until resources are available.
Out of space
Replication failed because the source system had insufficient space to create a new snapshot. This may be because there is no physical space available in the storage pool or because the project or one of its shares would be over quota because of reservations that don't include snapshots.
Incompatible target
Replication failed because the target system is unable to receive the source system's data stream format. This can happen as a result of upgrading a source system and applying deferred updates without having upgraded and applied the same updates on the target. Check the release notes for the source system's software version for a list of deferred updates and whether any have implications for remote replication.
Replication failed, but no additional information is available on the source. Check the alert log on the target system and if necessary contact support for assistance. Some failure modes that currently fall into this category include insufficient disk space on the target to receive the update and attempting to replicate a clone whose origin snapshot does not exist on the target system.

A replication update fails if any part of the update fails. The current implementation replicates the shares inside a project serially and does not rollback changes from failed updates. As a result, when an update fails, some shares on the target may be up-to-date while others are not. See "Snapshots and Data Consistency" above for details.

Although some data may have been successfully replicated as part of a failed update, the current implementation resends all data that was sent as part of the previous (failed) update. That is, failed updates will not pick up where they left off, but rather will start where the failed update started.

When manual or scheduled updates fail, the system does not automatically try again until the next scheduled update (if any). When continuous replication fails, the system waits several minutes and tries again. The system will continue retrying failed continuous replications indefinitely.

When a replication update is in progress and another update is scheduled to occur, the latter update is skipped entirely rather than started immediately after the previous update completes. The next update will be sent only when the next update is scheduled to occur. The system posts an alert when an update is skipped for this reason.