E-Series

NetApp® E-Series Storage Systems

Mirroring Feature Guide

NetApp, Inc. Telephone: +1 (408) 822-6000 Part number: 215-08315_B0

495 East Java Drive Fax: +1 (408) 822-4501 May 2015
Sunnyvale, CA 94089 Support telephone: +1 (888) 463-8277
U.S. Web: www.netapp.com
Feedback: doccomments@netapp.com
 Table of Contents | 3

Contents
About this guide ............................................................................................ 4
Mirroring features ........................................................................................ 5
About the mirroring features ...................................................................... 6
How does asynchronous mirroring differ from synchronous mirroring? .................... 6
Understanding Synchronous Mirroring write modes .................................................. 8
Features of asynchronous mirroring ............................................................................ 8
What is an asynchronous mirror group? ......................................................... 9
What is an asynchronous mirrored pair and a mirror repository? ................... 9
What you need to know about Asynchronous Mirroring .............................. 10
Features of Synchronous Mirroring .......................................................................... 13
What you need to know about Synchronous Mirroring ................................ 13
Managing the mirror relationship between two volumes .......................................... 17
About primary volumes and secondary volumes in a mirror relationship .... 17
About mirror repository volumes .................................................................. 18
Resynchronizing volumes in a mirror relationship ....................................... 19
Reversing the roles in a mirror relationship .................................................. 20
Removing the mirror relationship between two volumes ............................. 21
Suspending a mirrored pair ........................................................................... 22
Resuming a mirrored pair .............................................................................. 23
Using other features with mirroring .......................................................................... 23
Using the SANshare storage partitioning feature with Synchronous
Mirroring ................................................................................................. 24
Using the Volume Copy feature with mirroring ............................................ 24
Using the Dynamic Volume Expansion feature with mirroring .................... 24
Copyright information ............................................................................... 25
Trademark information ............................................................................. 26
How to send comments about documentation and receive update
notifications ............................................................................................ 27
4

About this guide

The information in this guide provides the conceptual framework necessary to understand the
Mirroring Features used with SANtricity Storage Manager Version 11.10. To access this software, go
to the NetApp Support Site at support.netapp.com.
Some software features described in this document might not be available for your NetApp E-Series
Storage System. For questions about available features, contact your NetApp account representative.
Note: The SANtricity Storage Manager software is also referred to as the storage management
software.
 5

Mirroring features
This document provides a functional overview of the Asynchronous Mirroring feature and the
Synchronous Mirroring feature.

Features activation
Like other features, you must enable the Asynchronous Mirroring feature and the Synchronous
Mirroring feature by purchasing a feature key file for each mirroring feature that you want to use and
applying the key through the features dialog. You must enable the feature on both the primary storage
array and the remote storage array. Unlike other features, you must activate the mirroring feature
after you enable it.
Contact technical support to purchase a feature key file.
6

About the mirroring features

The Asynchronous Mirroring feature and the Synchronous Mirroring feature are for online, real-time
replication of data between two storage arrays in separate locations.
With Asynchronous Mirroring or Synchronous Mirroring, you can create mirrored pairs to copy data
from one storage array to another storage array to protect against local or wide area disasters, or
centrally back up your data at a remote location.
The mirrored volume pair is created from two volumes, which are logical structures that are created
on a storage array for data storage. The pair consists of a primary volume at a local storage array and
a secondary volume at a remote storage array.
If a disaster occurs, or if there is a catastrophic failure in the local storage array, you can promote the
secondary volume in the remote storage array to the role of primary volume to take over
responsibility for maintaining computer operations.

Related concepts
How does asynchronous mirroring differ from synchronous mirroring? on page 6
Understanding Synchronous Mirroring write modes on page 8
Features of asynchronous mirroring on page 8
Features of Synchronous Mirroring on page 13
Managing the mirror relationship between two volumes on page 17
Using other features with mirroring on page 23

How does asynchronous mirroring differ from synchronous

mirroring?
The Storage Management Software provides two types of mirror methods:

• Asynchronous Mirroring is a remote point-in-time replication method.

• Synchronous Mirroring is a continuous remote replication method for mirrored volumes and co-
exists with the Asynchronous Mirroring feature.
The Synchronous Mirroring feature includes an asynchronous write mode, which is different from
the Asynchronous Mirroring feature. With the asynchronous write mode, host write requests that
are written to the primary volume are copied to the secondary volume on the remote storage array
on a periodic basis, whereas the Asynchronous Mirroring feature captures the differences between
the current point-in-time image and the previous one and copies them to the remote storage array.

When you upgrade to a release that supports both mirror features, the Synchronous Mirroring
configurations and the new Asynchronous Mirroring configurations are unaffected and continue to
operate normally.
Note: The asynchronous write mode previously available in the legacy Synchronous Mirroring
feature is only supported on the E2600 controller and the E5400 controller. It is not supported on
later controller models. The new Asynchronous Mirroring feature is the preferred method to use to
achieve the asynchronous write mode when mirroring.

Differences between mirroring features

Asynchronous Mirroring differs from Synchronous Mirroring in one essential way: it captures the
state of the source volume at a particular point in time and copies just the data that has changed since
the last image capture.
 About the mirroring features | 7

• With Asynchronous Mirroring, the remote storage array is not fully synchronized with the local
storage array, so if the application needs to transition to the remote storage array due to a loss of
the local storage array, some transactions could be lost.

• With Synchronous Mirroring the state of the source volume is not captured at some point in time,
but rather reflects all changes that were made on the source volume to the target volume. The
copy is identical to production data at every moment because, with this type of mirror, each time a
write is done to the production volume, a write is done to the remote volume. The host does not
receive an acknowledgment that the write was successful until the remote volume is successfully
updated with the changes that were made on the production volume.

Comparison between mirroring features

Asynchronous Mirroring Synchronous Mirroring

Replication Method

• Point-in-Time • Continuous
Mirroring is done on demand or Mirroring is automatically executed
automatically according to a user- continuously, copying data from every host
defined schedule. Schedules can be write.
defined at the granularity of minutes.

Repository

• Multiple • Single
A repository is required for each Single repository for all mirrored volumes.
mirrored pair.

Synchronization

• Writes Only Changed Data • Writes All Data

Differences between the current point- All writes captured on the primary volume are
in-time image and the previous one are copied to the secondary volume.
copied to the remote storage array.

Communication

• iSCSI and Fibre Channel • Fibre Channel

Supports iSCSI and Fibre Channel Supports only Fibre Channel interfaces between
interfaces between storage arrays. storage arrays.

Distance

• Unlimited • Restricted
Support for virtually unlimited distances Typically must be within about 10 km (6.2
between the local storage array and the miles), of the local storage array to meet the
remote storage array, with the distance latency and application performance
typically limited only by the capabilities requirements.
of the network and the channel
extension technology.

Typical use scenarios

Asynchronous mirroring is ideal for satisfying the demand for non-stop operations and, in general, is
far more network efficient for periodic processes, such as backup and archive.
8 | Mirroring Feature Guide

Although Synchronous Mirroring is ideal for continuous replication between a small number of
systems for business continuity purposes, it is not ideal for periodic processes such as backup and
archive.
Reasons for using asynchronous mirroring
• Remote backup consolidation

• Wide area content distribution

• Long distance disaster recovery

• Backup of 24 x 7 application data

• Application development and testing on a point-in-time image of live data

• Application data replication to secondary site

Reasons for using synchronous mirroring

• Data center type environment for top-tier applications and data

• Protection of databases and other highly transactional applications

• Local and near-local disaster recovery; secondary data center in the same metro area

• Business continuity during scheduled maintenance of the primary storage array, with the
secondary system acting as the primary system

Understanding Synchronous Mirroring write modes

The type of write mode that you chose when you create the remote mirror determines when the I/O
completion indication is sent to the host software application, which signals that the data has
successfully been copied to the secondary storage array. You can choose one of the following write
modes.

• Synchronous Write Mode (Recommended)

This write mode offers the best chance of full data recovery from the secondary storage array in
the event of a disaster, at the expense of host I/O performance. When you select this write mode,
any host write requests are written to the primary volume and then copied to the secondary
volume. The controller sends an I/O completion indication to the host system after the copy has
been successfully completed. This write mode is selected by default and is the recommended
write mode.

• Asynchronous Write Mode

This write mode offers faster host I/O performance, but it does not guarantee that the copy has
been successfully completed before processing the next write request. When you select this write
mode, host write requests are written to the primary volume. The controller sends an I/O
completion indication back to the host system before the data has been successfully copied to the
secondary storage array.

You can use consistency groups for Synchronous Mirroring. Consistency groups help ensure
consistent remote copies of data from one or more applications for disaster recovery purposes.
Mirrored volumes stay in sync and are recoverable in the event of an outage at the primary site.
Synchronous Mirroring supports one consistency group per storage array.

Features of asynchronous mirroring

The features of asynchronous mirroring include the following:
 About the mirroring features | 9

• Self-Consistent Data: Data on the remote storage array is protected during the synchronization
process so that writes to the remote storage array do not render the data unusable.

• Minimizes Performance Impact: Copying data from the local storage array to the remote
storage array asynchronously decouples host I/O requests from the remote synchronization
process, minimizing the performance impact to the hosts accessing the local storage array.

• Schedule-Based or On-Demand Replication: Enables a user-configurable schedule for

automatic, interval-based replication of changes, or a manual (or scripted) user command.

• Heterogeneous Protocol Environment: Enables asynchronous mirroring of data between storage

arrays that are different in terms of hardware type. For example, an E5400 controller can mirror
with an E2600 controller as long as the mirroring implementations on the two storage arrays are
compatible and both storage arrays support a common inter-controller communication channel,
either Fibre Channel or iSCSI protocol.

• Flexible Remote Communication Methods: Allows the local and remote storage arrays to
connect through a Fibre Channel fabric interface, iSCSI interface or both.

Related concepts
What is an asynchronous mirror group? on page 9
What is an asynchronous mirrored pair and a mirror repository? on page 9
What you need to know about Asynchronous Mirroring on page 10

What is an asynchronous mirror group?

An asynchronous mirror group is a container that can house several mirrored pairs, which are
synchronized as a coordinated data set to provide a consistent data set at the remote site. The
asynchronous mirror group is associated with a local storage array and a remote storage array that are
used for mirroring.

• The local storage array will be the primary side of the mirror group, while the remote storage
array will be the secondary side of the mirror group.

• All volumes added to the mirror group on the local storage array will hold the primary role in the
mirror relationship.

• All volumes added to the mirror group on the remote storage array will hold the secondary role in
the mirror relationship.

• The types of volumes that might participate in a mirror relationship are a standard volumes and
thin volumes. Snapshot volumes cannot participate.

Because applications might need to use more than one volume, asynchronous mirror groups allow
multiple mirrored pairs to be synchronized and managed as a group. This ensures that all of the
secondary volumes in the same mirror group are always synchronized to the exact same point in time.
You create an asynchronous mirror group to define the synchronization settings for all mirrored pairs
within the mirror group. Each mirrored pair in an asynchronous mirror group share the same
synchronization settings, primary and secondary role, and write mode.

What is an asynchronous mirrored pair and a mirror repository?

An asynchronous mirrored pair is comprised of two volumes, a primary volume and a secondary
volume, that contain identical copies of the same data. The mirrored pair is a part of an asynchronous
mirror group, which allows the mirrored pair to synchronize at the same time as any other mirrored
pairs within the mirror group. Write operations are performed first to the primary volume and then to
the secondary volume.
10 | Mirroring Feature Guide

What kind of volumes can be used?

Standard volumes and thin volumes can be used for an asynchronous mirrored pair, however, the
primary volume must be paired with a secondary volume that is the same volume type.
Operational differences when using thin volumes for Asynchronous Mirroring
The operational differences when using thin volumes are as follows:

• If an existing thin volume is used to complete an asynchronous mirrored pair by adding it to the
secondary side of the asynchronous mirror group, that thin volume is re-initialized with a new
repository. Only provisioned blocks on the primary side are transferred during the initial
synchronization process.
• For thin volumes to be considered as valid primary volume or secondary volume candidates,
Auto-Expansion must be enabled. Thin volumes with Auto-Expansion disabled are not shown as
candidates for asynchronous mirroring.

• The provisioned capacity quota and growth alert thresholds can be changed only on the primary
side of an asynchronous mirrored pair. Any changes to these parameters on the primary side are
automatically propagated to the secondary side.

• Removing a thin volume from an asynchronous mirror group does not cause any changes to the
parameters controlling its capacity expansion.

About mirror repository volumes

Special mirror repository volumes are used to manage mirror data synchronization. Mirror repository
volumes are required for both the primary volume and the secondary volume in a mirrored pair.
A mirror repository stores three types of data.

1. The first is a repository used for preserving resynchronization images on the primary volume and
recovery point images on the secondary volume.

2. The second type of data is a pair of delta logs that are used to track regions on the primary
volume that are written between synchronization intervals. The delta logs are used only on the
primary side of the mirrored pair, but they also must be allocated on the secondary side of the
mirrored pair because a role-reversal can occur at any time.

3. The third type of data is a log that tracks synchronization statistics on a per mirrored pair basis.

What you need to know about Asynchronous Mirroring

This topic describes what you need to know before you start using asynchronous mirroring.

Using mirrored volume candidates and storage array mirrors

The following notes apply to mirrored volume candidates and storage array mirrors.

• RAID level, caching parameters, and segment size can be different on the two mirrored volumes.

• The secondary volume must be at least as large as the primary volume.

• A primary volume can be only a source volume in a volume copy. A secondary volume cannot be
a source volume or a target volume unless a role reversal was initiated after the copy has
completed. If a role reversal is initiated during a Copy in Progress status, the copy fails and
cannot be restarted.

• A given volume may participate in only one mirror relationship.

• A volume participating in a copy request cannot be a mirrored secondary volume.

 About the mirroring features | 11

Note: Asynchronous mirroring is supported only in dual-controller hardware configurations.

Requirements for using Asynchronous Mirroring

Keep in mind the following requirements when using asynchronous mirroring.

• You must have two storage arrays.

• You must have write access to both storage arrays.

• You must have enough space on the remote site for the remote copy of production data.
• Mirror repository volumes are required for both the primary volume and the secondary volume in
a mirrored pair.

• Inter-controller communication for the asynchronous mirroring feature uses the host-connected
ports to initiate connections to the remote storage array and is only supported on controllers with
Fibre Channel or iSCSI host-connect ports.

• SAS and InfiniBand are not supported as inter-array communication channels.

• The connection between the two storage arrays must be capable of transferring data at a rate that
ensures that all data written to the collection of primary volumes in a 24-hour period can be
copied to the secondary storage array within that same 24-hour period.

FC Connection and iSCSI connection requirements

• Fibre Channel Connection Requirements:

◦ You must attach dedicated asynchronous mirroring ports to a Fibre Channel fabric
environment. In addition, these ports must support the Name Service.

◦ You can use a fabric configuration that is dedicated solely to the asynchronous mirroring ports
on each controller. In this case, host systems can connect to the storage arrays using fabric.

◦ Fibre Channel Arbitrated Loop (FC-AL), or point-to-point configurations are not allowed for
inter-array connections. FC-AL/P2P is for host connections only. These configurations are
independent of the dedicated asynchronous mirroring fabric.

◦ The maximum distance between the local site and the remote site is 10 km (6.2 miles), using
single-mode fibre gigabit interface converters (GBICs) and optical long-wave GBICs.

• iSCSI Connection Considerations:

◦ iSCSI does not require dedicated asynchronous mirroring ports when using asynchronous
mirroring.

◦ The iSCSI inter-controller communication must use a host-connect port and not the
management Ethernet port.

◦ The controller maintains a list of the remote storage arrays to which the iSCSI initiator
attempts to establish a session. The first port that successfully establishes an iSCSI connection
is used for all subsequent communication with that remote storage array. If communication
fails, a new session is attempted using all available ports.

• FC Connection and iSCSI Connection Considerations:

◦ There is no failover from one channel to the other.

◦ If both storage arrays are connected with both FC connections and iSCSI connections, one
asynchronous mirror group may be mirrored over FC and the other asynchronous mirror
group can be mirrored over iSCSI.
12 | Mirroring Feature Guide

Additional notes on using Asynchronous Mirroring

Connectivity and Volume The controller that owns the primary volume determines the
Ownership current owner of the secondary volume. The primary volume
and the secondary volume in a mirrored pair use the following
ownership rules:

• If the primary volume is owned by controller A on the

primary side, the secondary volume is owned by controller
A on the secondary side.

• If the primary volume is owned by controller B on the

primary side, the secondary volume is owned by controller
B on the secondary side.

• If primary controller A cannot communicate with

secondary controller A, controller ownership changes do
not take place. A primary controller attempts to
communicate only with its matching controller in the
secondary asynchronous mirror group.

The next remote write processed automatically triggers a

matching ownership change on the secondary side if one of
these conditions exists:

• When an I/O path error causes a volume ownership change

on the primary side.

• If the storage administrator changes the current owner of

the primary volume.
For example, a primary volume is owned by controller A,
and then you change the controller owner to controller B.
In this case, the next remote write changes the controller
owner of the secondary volume from controller A to
controller B. Because controller ownership changes on the
secondary side are controlled by the primary side, they do
not require any special intervention by the storage
administrator.

Controller Resets and Storage • Sometimes a remote write is interrupted by a controller

Array Power Cycles reset or a storage array power cycle before it can be
written to the secondary volume. The storage array
controller does not need to perform a full synchronization
of the mirrored pair in this case.

• A controller reset causes a controller ownership change on

the primary side from the preferred controller owner to the
alternate controller in the storage array.
• When a remote write has been interrupted during a
controller reset, the new controller owner on the primary
side reads information stored in a log file in the mirror
repository volume of the preferred controller owner. The
new controller owner then copies the affected data blocks
from the primary volume to the secondary volume,
eliminating the need for a full synchronization of the
mirrored volumes.
 About the mirroring features | 13

Force to Primary in the Event • In the event of a disaster at the primary site, you can force
of Disaster the asynchronous mirror group on the secondary side to
transition to the primary role. Then the recovery host is
able to access the newly promoted group, and business
operations can continue.

• Forced promotion of the asynchronous mirror group on the

secondary side causes all mirrored pairs in the group to
function as primary volumes, allowing write access and
tracking writes to resynchronize with the asynchronous
mirror group on the secondary side.

• Forced promotion of an asynchronous mirror group on the

secondary side is allowed only if all mirrored pairs of the
group had been previously synchronized and currently
have snapshot images of a consistent data set.

• If any mirrored pairs of the group were in the midst of the

initial synchronization, then forced promotion is not
allowed. If any mirrored pairs of the group do not have a
point-in-time image of the consistency point (e.g. due to a
full-repository error), the forced promotion is not allowed.

Features of Synchronous Mirroring

The features of Synchronous Mirroring include the following:

• Updates two distributed copies simultaneously.

• Mirrored volume pairs behave like one shared drive.

• Eliminates single points of failure.

• Replication is managed on a per-volume basis, so you can mirror individual volumes in a primary
storage array to appropriate secondary volumes in several different remote storage arrays.

Related concepts
What you need to know about Synchronous Mirroring on page 13

What you need to know about Synchronous Mirroring

This topic describes what you need to know before you start using Synchronous Mirroring.

Using mirrored volume candidates and storage array mirrors

The following notes apply to mirrored volume candidates and storage array mirrors.

• RAID level, caching parameters, and segment size can be different on the two mirrored volumes.

• The secondary volume must be at least as large as the primary volume.

• The only type of volume that may participate in a mirror relationship is a standard volume.
Snapshot volumes cannot participate.

• You can create a snapshot volume by using either a primary volume or a secondary volume as the
base volume.
14 | Mirroring Feature Guide

• A primary volume can be a source volume or a target volume in a volume copy. A secondary
volume cannot be a source volume or a target volume unless a role reversal was initiated after the
copy has completed. If a role reversal is initiated during a Copy in Progress status, the copy fails
and cannot be restarted.

• A given volume may participate in only one mirror relationship.

Connection requirements
Keep in mind the following connection requirements when using Synchronous Mirroring.
• You must attach dedicated Synchronous Mirroring ports to a Fibre Channel fabric environment. In
addition, these ports must support the Directory Service interface and the Name Service.

• You can use a fabric configuration that is dedicated solely to the Synchronous Mirroring ports on
each controller. In this case, host systems can connect to the storage arrays using fabric, Fibre
Channel Arbitrated Loop (FC-AL), or point-to-point configurations. These configurations are
totally independent of the dedicated Synchronous Mirroring fabric.

• Alternatively, you can use a single Fibre Channel fabric configuration for both the Synchronous
Mirroring connectivity and for the host I/O paths to the controllers.

• The maximum distance between the primary site and the secondary site is 10 km (6.2 miles),
using single-mode fiber gigabit interface converters (GBICs) and optical long-wave GBICs.

Additional notes on using Synchronous Mirroring

Journaling File Systems and When you are using a journaling file system, you cannot gain
Synchronous Mirroring read-only access to a remote volume. A journaling file system
does not let you mount the remote volume in Windows
(NTFS); however, you can mount the snapshot of the remote
volume.
 About the mirroring features | 15

Connectivity and Volume A primary controller attempts to communicate only with its
Ownership matching controller in the secondary storage array. For
example, controller A in the primary storage array attempts
communication only with controller A in the secondary storage
array. The controller (A or B) that owns the primary volume
determines the current owner of the secondary volume. If the
primary volume is owned by controller A on the primary side,
the secondary volume is owned by controller A on the
secondary side. If primary controller A cannot communicate
with secondary controller A, controller ownership changes do
not take place.
The next remote write processed automatically triggers a
matching ownership change on the secondary side if one of
these conditions exists:

• When an I/O path error causes a volume ownership change

on the primary side

• If the storage administrator changes the current owner of

the primary volume

For example, controller A owns a primary volume, and then

you change the controller owner to controller B. In this case,
the next remote write changes the controller owner of the
secondary volume from controller A to controller B. Because
controller ownership changes on the secondary side are
controlled by the primary side, they do not require any special
intervention by the storage administrator.
Controller Ownership/ During a remote volume mirroring operation, the same
Preferred Path controller must own both the primary volume and the
secondary volume. If both volumes do not have the same
preferred controller when a remote volume mirror starts, the
ownership of the secondary volume is automatically transferred
to the preferred controller of the primary volume.

• When the remote volume mirror is deleted, ownership of

the secondary volume is restored to its preferred controller.

• If ownership of the primary volume is changed and there

are host writes to the primary volume, ownership of the
secondary volume is also changed.
16 | Mirroring Feature Guide

Controller Resets and Storage • Sometimes a controller reset or a storage array power cycle
Array Power Cycles interrupts a remote write before it can be written to the
secondary volume. The storage array controller does not
need to perform a full synchronization of the mirrored
volume pair in this case.

• A controller reset causes a controller ownership change on

the primary side from the preferred controller owner to the
alternate controller in the storage array.
• When a remote write has been interrupted during a
controller reset, the new controller owner on the primary
side reads information stored in a log file in the mirror
repository volume of the preferred controller owner. The
new controller owner then copies the affected data blocks
from the primary volume to the secondary volume, which
eliminates the need for a full synchronization of the
mirrored volumes.

Link Interruptions or • When processing write requests, the primary controller may
Secondary Volume Errors be able to write to the primary volume, but a link
interruption prevents communication with the remote
secondary controller.

• In this case, the remote write cannot complete to the

secondary volume. The primary volume and the secondary
volume are no longer appropriately mirrored. The primary
controller changes the mirrored pair into Unsynchronized
status and sends an I/O completion to the primary host. The
primary host can continue to write to the primary volume,
but remote writes do not take place.

• When connectivity is restored between the current owner of

the primary volume and the current owner of the secondary
volume, re-synchronization takes place if you have selected
the option to automatically resynchronize upon restoration
of the link (You can also choose not to allow auto re-
synchronization.) Only the blocks of data that have changed
on the primary volume during the link interruption are
copied to the secondary volume. The mirrored pair changes
from an Unsynchronized state to Mirror Synchronization in
Progress status.

• The primary controller also marks the mirrored pair as

Unsynchronized when a volume error on the secondary side
prevents the remote write from completing. For example, an
offline secondary volume or a failed secondary volume can
cause the remote mirror to become unsynchronized. When
the volume error is corrected (the secondary volume is
placed online or is recovered to Optimal status), a full
synchronization automatically begins. The mirrored pair
then changes to Synchronization in Progress status.
 About the mirroring features | 17

Managing the mirror relationship between two volumes

Mirroring creates a set of consistent data that can be used by production applications in the event of
problems with production volumes or for other purposes.
Mirroring, whether Synchronous Mirroring or Asynchronous Mirroring, requires two or more storage
arrays. The source and target of the mirroring can reside on the same site and form a local mirror or
they can reside on different sites and enable a disaster recovery plan.
A volume is assigned either a primary role or a secondary role when the mirror relationship is
defined. By default, in a new mirror definition, the location of the primary volume designates the
local storage array, and the secondary volume designates the remote storage array. A mirror
relationship must have one primary volume and one secondary volume.
Attention: Possible loss of data access – You cannot create a mirror relationship if the primary
volume contains unreadable sectors. Furthermore, if an unreadable sector is discovered during a
mirroring operation, the mirror status changes to Unsynchronized.

Related concepts
About primary volumes and secondary volumes in a mirror relationship on page 17
About mirror repository volumes on page 18
Resynchronizing volumes in a mirror relationship on page 19
Reversing the roles in a mirror relationship on page 20
Removing the mirror relationship between two volumes on page 21
Suspending a mirrored pair on page 22
Resuming a mirrored pair on page 23

About primary volumes and secondary volumes in a mirror relationship

Before you can use either Asynchronous Mirroring or Synchronous Mirroring feature, you must
enable and activate the mirroring feature that you intend to use on both the local storage array and the
remote storage array. If a volume does not exist on either the local storage array or the remote storage
array, you must create the volumes. Both the local storage array and the remote storage array show
the primary volume and the secondary volume.
When both the primary volume and the secondary volume are available, you can create a mirrored
pair. When the remote mirrored volume is first created, a full synchronization automatically occurs.
The data from the primary volume is copied completely to the secondary volume.

Related concepts
Prerequisites for creating a mirror relationship between two volumes on page 17

Prerequisites for creating a mirror relationship between two volumes

Make sure that the following prerequisites have been met before you create a mirror relationship
between two storage arrays.

Asynchronous Mirroring
• The Asynchronous Mirroring feature must be enabled and activated on the local and remote
storage arrays that is used for mirroring.

• The local storage array and the remote storage array must be connected through a proper Fibre
Channel fabric or iSCSI interface.
18 | Mirroring Feature Guide

• The remote storage array must contain a volume that has a capacity that is greater than or equal to
the capacity of the mirrored volume that is to be used as the primary volume on the local storage
array.

• You can protect your mirror group with Full Disk Encryption (FDE), but the drive attributes must
match on both the primary volume on the local storage array and the secondary volume on the
remote storage array regardless of whether FDE is enabled or disabled.

• The primary volume on the local storage array must match the Data Assurance (DA) settings as
the secondary volume on the remote storage array.
• Make sure that you know the password for the local storage array and remote storage array.

Synchronous Mirroring
• The Synchronous Mirroring feature has been activated.

• The local storage array contains two mirror repository volumes.

• The local storage array contains the primary volume, and the remote storage array contains the
secondary volume. If either volume does not exist, you must create it before you can create the
remote volume mirror.

• The secondary volume meets these requirements:

◦ The local storage array and the remote storage array must be connected through a proper Fibre
Channel fabric interface.

◦ The secondary volume on the remote storage array must match the Data Assurance (DA)
settings as the primary volume on the local storage array.

◦ The Full Disk Encryption (FDE) settings on the secondary volume can be different from the
FDE settings on the primary volume.

◦ The RAID level of the secondary volume can be different from the RAID level of the primary
volume.

◦ The capacity of the secondary volume must be equal to or greater than the capacity of the
primary volume.

About mirror repository volumes

For the Asynchronous Mirroring feature, a mirror repository volume is required for both the primary
volume and the secondary volume in a mirrored pair. The Synchronous Mirroring feature requires
two mirror repositories, one for each controller, which are created during activation and then used for
all Synchronous Mirroring relationships. The controller stores mirroring information on the mirror
repository volume, which includes information about remote writes that are not yet complete. You
can use this information to recover from controller resets and the accidental shutting down of storage
arrays.
Mirror repository volume details
• You can create the mirror repository volume from the unconfigured free capacity of a volume
group or a disk pool.

• You can create a new volume group or a new disk pool and its member mirror repository volume
from the unconfigured free capacity of the storage array.

• The Synchronous Mirroring activation process creates two mirror repository volumes with equal
capacity. The default capacity for the mirror repository volumes is 128 MB. You can neither
increase the capacity nor decrease the capacity.
 About the mirroring features | 19

• When you activate the Synchronous Mirroring feature and create the volume group and mirror
repository volumes from the unconfigured free capacity of the storage array, you select the RAID
level. However, when you create the mirror repository volumes from an existing storage array,
you do not select the RAID level.

• For Asynchronous Mirroring, the minimum mirror repository size is the minimum of 0.02 percent
of the base volume capacity or 32 MB; the maximum mirror repository size is 101 percent of the
base volume capacity.

• For Asynchronous Mirroring, primary and secondary mirror repository volumes are not required
to be the same size. Mirror repository volumes can be created on separate volume groups with
different RAID levels. However, mirror repository volumes must have compatible security and
data assurance and quality of service of the associated mirrored volume.

Attention: Potential loss of data – Because the data stored on the mirror repository volumes is
critical, do not create mirror repository volumes in an existing volume group that has RAID Level
0. If you create a new volume group for the mirror repository volumes, do not select RAID Level
0.

Resynchronizing volumes in a mirror relationship

This section describes the methods for re-synchronizing data in Asynchronous Mirroring and in
Synchronous Mirroring. You might need to periodically test the communication between the primary
storage array and the local storage array before resynchronizing the data.
Note: The Manual Resynchronization option is the recommended method because it lets you
manage the resynchronization process in a way that provides best opportunity for recovering data.

Asynchronous Mirroring resynchronization

The following describes the Asynchronous Mirroring resynchronization methods.

• Manual
Manual resynchronization means that you can manually start resynchronization of the data on all
of the mirrored pairs within the asynchronous mirror group
If a communication failure occurs between the primary volume and the secondary volume of the
mirrored pairs, at least one of the mirrored pairs within the asynchronous mirror group is in a
Stopped or Failed status and the asynchronous mirror group is in an Internally-Suspended state.
Any write requests to the primary volume of the mirrored pairs are logged, and a Needs Attention
status appears for the storage array.
After the controller owner of the primary volume detects that communication has been restored,
you must recover all the mirrored pairs that are in a in a Stopped or Failed status within the
asynchronous mirror group and then resume the Internally-Suspended asynchronous mirror
group.

• Automatic
Automatic resynchronization means that resynchronization of the data is handled automatically
based on user-configurable synchronization settings (interval-based) that were set up when
creating the asynchronous mirror group.
If a communication failure occurs between the local storage array and the remote storage array,
the volumes on the remote storage array become inaccessible. After the controller owner on the
primary storage array detects that communication has been restored, it automatically re-starts the
synchronization process.

Synchronous Mirroring resynchronization

The following describes the Synchronous Mirroring resynchronization methods.

• Manual
20 | Mirroring Feature Guide

Manual resynchronization means that you can manually start resynchronization of the data on the
primary volume and the secondary volume after communication has been restored to the
unsynchronized mirrored pair.
If a communication failure occurs between the primary volume and the secondary volume, the
volumes on the remote storage array become inaccessible. After the controller owner of the
primary volume detects that communication has been restored, the remote mirror stays in an
Unsynchronized status until you resume the mirrored pair.

• Automatic
When the Automatic Resynchronization option is selected and a communication failure occurs
between the primary storage array and the local storage array, the controller owner of the primary
volume starts resynchronizing the primary volume and the secondary volume. This action occurs
immediately after the controller owner detects that communication has been restored for an
Unsynchronized mirrored pair.
When connectivity is restored between the current owner of the primary volume and the current
owner of the secondary volume, only the blocks of data that have changed on the primary volume
during the link interruption are copied to the secondary volume. The mirrored pair changes from
an Unsynchronized state to Mirror Synchronization in Progress status.
The primary controller also marks the mirrored pair as Unsynchronized when a volume error on
the secondary side prevents the remote write from completing. For example, an offline secondary
volume or a failed secondary volume can cause the remote mirror to become unsynchronized.
When the volume error is corrected (the secondary volume is placed online or is recovered to
Optimal status), a full synchronization automatically begins. The mirrored pair then changes to
Synchronization in Progress status.

Reversing the roles in a mirror relationship

Asynchronous Mirroring
Use the Change Role option to perform a role reversal between asynchronous mirror groups. You
can either promote the selected asynchronous mirror group to a primary role or demote the selected
asynchronous mirror group to a secondary role.

• A suspended asynchronous mirror group resumes during the change role operation.

• The role reversal change affects all mirrored pairs within the selected asynchronous mirror group.
For example, when a primary asynchronous mirror group is demoted to a secondary role, all the
primary volumes of the mirrored pairs in that mirror group are also demoted to secondary
volumes.

• If you are demoting a primary asynchronous mirror group to a secondary role and the current
secondary asynchronous mirror group can be contacted, the secondary asynchronous mirror group
is automatically promoted to a primary role in the mirror relationship. Likewise, if you are
promoting a secondary asynchronous mirror group to a primary role and the current primary
asynchronous mirror group can be contacted, the primary asynchronous mirror group is
automatically demoted to a secondary role in the mirror relationship.

• You also can use the Change Role option during a Recovery Guru procedure for a dual primary
Asynchronous Mirroring condition. To avoid the dual primary Asynchronous Mirroring condition
and subsequent recovery steps, wait until the connection between the storage arrays is operational
to perform the role reversal.

Synchronous Mirroring
If the primary volume in a remote volume mirror fails in a disaster situation, you can reverse the roles
of the primary volume and the secondary volume to transfer the data back to the restored volume.
Reversing the roles promotes the secondary volume to the role of primary volume and demotes the
primary volume to the role of secondary volume in a remote volume mirror.
 About the mirroring features | 21

Note: Potential loss of data access – If you try to reverse roles between the secondary volume and
the primary volume while a volume copy is in progress, the role reversal succeeds, but the volume
copy fails and cannot be restarted.

Keep the following guidelines in mind when performing a role reversal between mirror groups:

• You cannot perform a volume copy on a secondary volume in a remote volume mirror. To create a
volume copy of a secondary volume, you must reverse the roles of the secondary volume and the
primary volume, and then perform the volume copy on the new primary volume.

• While a remote volume mirror is synchronizing, you cannot perform a volume copy on either the
primary volume or the secondary volume.

Removing the mirror relationship between two volumes

Asynchronous Mirroring
Use the Remove Mirrored Pair option to remove the mirror relationship between the two volumes
in an Asynchronous Mirroring relationship.
Removing an asynchronous mirrored pair from an asynchronous mirror group breaks the mirror
relationship between the primary volume on the local storage array and the secondary volume on the
remote storage array. Data on the volumes is not affected. As a result of this operation, the primary
volume and the secondary volume become standard, host-accessible, non-mirrored volumes.
Keep these guidelines in mind when removing an asynchronous mirrored pair:

• This option is not available unless the asynchronous mirror group contains mirrored pairs.

• This option is available either by selecting the individual mirrored pair itself, or by selecting the
associated asynchronous mirror group.

• The mirror relationship is first removed on the local storage array and then on the remote storage
array. Sometimes, the mirror relationship is successfully removed on the local storage array but
cannot be removed on the remote storage array because of a communication problem. In this case,
an error message appears, which shows the following information:

◦ The name of the remote storage array with the orphaned mirrored pair

◦ The name of the volume

To resolve the problem, open the Array Management Window for the remote storage array,
select the orphaned mirrored pair, and remove the mirror relationship.

• Sometimes, the mirror relationship is successfully removed on the remote storage array, but not
on the local storage array. In this case, the next synchronization operation from the primary
volume to the secondary volume causes the synchronization process to pause. The Logical pane
of the primary Array Management Window also shows an unresponsive remote secondary
volume. Remove the mirror relationship on the local storage array to correct the problem.

Synchronous Mirroring
Use the Remove Mirror Relationship option to remove the mirror relationship between the two
volumes in a Synchronous Mirroring relationship.
Keep these guidelines in mind when removing the mirror relationship between the two volumes.

• This option is not available unless defined mirror relationships exist on the storage array.

• This option does not delete the primary volume, secondary volume, or the mirror repository
volumes that support Synchronous Mirroring for the storage arrays. Data on the volumes is not
affected. As a result of this operation, the primary volume and the secondary volume become
standard, host -accessible, non-mirrored volumes.
22 | Mirroring Feature Guide

• This option is only available for the local volume (primary or secondary) that is present in the
storage array that you are currently managing. This option is not available if you select a remote
secondary volume in the Logical pane.

• The mirror relationship is first removed on the local storage array and on the remote storage array.
Sometimes, the mirror relationship is successfully removed on the local storage array but cannot
be removed on the remote storage array because of a communication problem. In this case, an
error message appears, which shows the following information:

◦ The name of the remote storage array with the orphaned mirrored volume
◦ The name of the volume

To resolve the problem, open the Array Management Window for the remote storage array, select
the specified volume, and remove the mirror relationship.

◦ Sometimes, the mirror relationship was successfully removed on the secondary side, but not
the primary side. In this case, the first I/O write to the primary volume causes the mirror state
to change to Unsynchronized. The Logical pane of the primary Array Management Window
also shows an unresponsive remote secondary. Remove the mirror relationship on the primary
storage array to correct the problem.

Attention: Do not remove a mirror relationship to back up a mirrored volume. To perform backups
of either the primary volume or the secondary volume, suspend the remote volume mirror so that
the mirror relationship is not broken or take a snapshot of the primary or secondary volume, and
backup the snapshot.

Suspending a mirrored pair

Asynchronous Mirroring
Use the Suspend option to suspend data transfer between all mirrored pairs in an asynchronous
mirror group without removing the mirror relationship.
The Suspend option lets you suspend the synchronization of data on all mirrored pairs at the
asynchronous mirror group level. This option is more efficient than suspending mirrored pairs
individually.
When an asynchronous mirror group is in a Suspended state, no attempt is made to copy data from
the primary volumes to the secondary volumes of the mirrored pairs. Any writes to the primary side
of the asynchronous mirror group are persistently logged in its associated mirror repository volumes.
After the asynchronous mirror group is resumed, only the modified regions of the primary volumes
are written to the secondary volumes.
Note: The Suspend Asynchronous Mirror Group option is available on the local storage array
only. This option is not available on the remote storage array.

Keep these guidelines in mind when you suspend an asynchronous mirror group:

• Any data that is written to the primary side of the asynchronous mirror group is logged while the
mirror group is suspended and is written automatically to the secondary side of the asynchronous
mirror group when the mirror group is resumed. A full synchronization is not required.

• The state of the asynchronous mirror group and mirrored pairs stays suspended until you use the
Resume option to resume synchronization activity.

Synchronous Mirroring
Use the Suspend option to suspend data transfer between a primary volume and a secondary volume
that are participating in Synchronous Mirroring without removing the mirror relationship.
 About the mirroring features | 23

The Suspend option lets you control when the data on the primary volume and the secondary volume
should be synchronized. This option helps to reduce any performance impact to the host application
that might occur while any changed data on the primary volume is copied to the secondary volume.
When a remote mirror is in a Suspended status, no attempt is made to contact the secondary volume.
Any writes to the primary volume are persistently logged in the mirror repository volumes. After the
mirrored pair is resumed, only the modified regions of the primary volume are written to the
secondary volume.
Attention: Possible loss of data access – If the selected mirrored pair is part of a write consistency
mode group, you will automatically suspend all mirrored pairs in the write consistency mode
group. Use the command line interface to resume single write-consistent mirrored pairs.

Keep these guidelines in mind when you suspend a mirrored pair:

• Any data that is written to the primary volume will be logged while the mirrored pair is
suspended, and will be written automatically to the secondary volume when Synchronous
Mirroring is resumed. A full synchronization is not required.

• The state of the remote mirror stays suspended until you use the Resume Mirrored Pair option
to resume synchronization activity.

Resuming a mirrored pair

Asynchronous Mirroring
Use the Resume Asynchronous Mirror Group option to resume data transfer between all mirrored
pairs in an asynchronous mirror group. Data written to the primary volumes while the asynchronous
mirror group was suspended is written to the secondary volumes immediately. Periodic
synchronization resumes if an automatic synchronization interval has been set.The Resume
Asynchronous Mirror Group option enables you to resume synchronization of data for all mirrored
pairs at the asynchronous mirror group level. After an asynchronous mirror group is resumed, only
the modified regions of the primary volumes are written to the secondary volumes.
The Resume Asynchronous Mirror Group option is available on the local storage array only. This
option is not available on the remote storage array.

Synchronous Mirroring
Use the Resume Synchronous Mirroring dialog to resume data transfer between a primary volume
and a secondary volume participating in Synchronous Mirroring, after the mirror has been suspended
or unsynchronized. When a remote volume mirror is suspended, data continues to be written to the
primary volume, but the data is not written to the secondary volume. Writes to the primary volume
are persistently logged in to the mirror repository volumes
After communications are restored in a remote volume mirror, data transfer between the primary
volume and the secondary volume must be resynchronized. After the remote volume mirror resumes,
data is automatically written to the secondary volume. Only the regions of the primary volume that
changed since the mirrored pair was suspended are written to the secondary volume.

Using other features with mirroring

You can use the Mirroring features with the following features that are enabled and active on the
primary storage array.

• SANshare® Storage Partitioning

• Snapshot Volume

• Volume Copy
24 | Mirroring Feature Guide

• Dynamic Volume Expansion (DVE)

Related concepts
Using the SANshare storage partitioning feature with Synchronous Mirroring on page 24
Using the Volume Copy feature with mirroring on page 24
Using the Dynamic Volume Expansion feature with mirroring on page 24

Using the SANshare storage partitioning feature with Synchronous

Mirroring
The SANshare Storage Partitioning feature lets hosts share access to volumes in a storage array. A
storage partition is created when you define a collection of hosts (a host group) or a single host and
then define a volume-to-logical unit number (LUN) mapping. This mapping lets you define which
host group or host will have access to a particular volume in the storage array.
The storage partition definitions for the local storage array and the remote storage array are
independent of each other. If these definitions are put in place while the secondary volume is in a
secondary role, it reduces the administrative effort that is associated with site recovery if it becomes
necessary to promote the volume to a primary role.

Using the Volume Copy feature with mirroring

The Volume Copy feature copies data from a source volume to a target volume within the same
storage array.
Attention: Potential loss of data access – If a role reversal is started while a volume copy is in
progress, the volume copy fails and cannot be restarted.

• For Synchronous Mirroring, a primary volume in a remote volume mirror can be either a source
volume or a target volume in a volume copy. For Asynchronous Mirroring, a primary volume in a
remote volume mirror can only be a source volume in a volume copy.

• You can create a volume copy on the primary volume in a mirrored pair, but you cannot create a
volume copy on a secondary volume in a mirrored pair. You can make a copy of a secondary
volume in two ways:

◦ Promote the secondary volume to the role of primary volume.

◦ Create a snapshot volume of the secondary volume, and then perform a volume copy on the
snapshot volume.

Using the Dynamic Volume Expansion feature with mirroring

Dynamic Volume Expansion (DVE) increases the capacity of a volume. The increased capacity is
achieved by using the free capacity that is available on the volume group of the standard volume or
the snapshot repository volume. The new usable mirror capacity is limited by the smaller of the
primary volume and secondary volume of the mirrored pair.
Performing a DVE operation does not interrupt access to data on volume groups, volumes, or drives.
You can perform a DVE operation on a primary volume or a secondary volume of a mirrored pair.
However, you cannot perform a DVE operation on a mirror repository volume.
Note: To perform a DVE operation, the remote volume mirror must be in an Optimal status. The
Properties pane in Logical view shows the status of a volume.
 25

Copyright information
Copyright © 1994–2015 NetApp, Inc. All rights reserved. Printed in the U.S.
No part of this document covered by copyright may be reproduced in any form or by any means—
graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an
electronic retrieval system—without prior written permission of the copyright owner.
Software derived from copyrighted NetApp material is subject to the following license and
disclaimer:
THIS SOFTWARE IS PROVIDED BY NETAPP "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE,
WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
NetApp reserves the right to change any products described herein at any time, and without notice.
NetApp assumes no responsibility or liability arising from the use of products described herein,
except as expressly agreed to in writing by NetApp. The use or purchase of this product does not
convey a license under any patent rights, trademark rights, or any other intellectual property rights of
NetApp.
The product described in this manual may be protected by one or more U.S. patents, foreign patents,
or pending applications.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987).
26

Trademark information
NetApp, the NetApp logo, Go Further, Faster, AltaVault, ASUP, AutoSupport, Campaign Express,
Cloud ONTAP, Clustered Data ONTAP, Customer Fitness, Data ONTAP, DataMotion, Fitness, Flash
Accel, Flash Cache, Flash Pool, FlashRay, FlexArray, FlexCache, FlexClone, FlexPod, FlexScale,
FlexShare, FlexVol, FPolicy, GetSuccessful, LockVault, Manage ONTAP, Mars, MetroCluster,
MultiStore, NetApp Insight, OnCommand, ONTAP, ONTAPI, RAID DP, RAID-TEC, SANtricity,
SecureShare, Simplicity, Simulate ONTAP, Snap Creator, SnapCenter, SnapCopy, SnapDrive,
SnapIntegrator, SnapLock, SnapManager, SnapMirror, SnapMover, SnapProtect, SnapRestore,
Snapshot, SnapValidator, SnapVault, StorageGRID, Tech OnTap, Unbound Cloud, and WAFL and
other names are trademarks or registered trademarks of NetApp, Inc., in the United States, and/or
other countries. All other brands or products are trademarks or registered trademarks of their
respective holders and should be treated as such. A current list of NetApp trademarks is available on
the web at http://www.netapp.com/us/legal/netapptmlist.aspx.
 27

How to send comments about documentation and

receive update notifications
You can help us to improve the quality of our documentation by sending us your feedback. You can
receive automatic notification when production-level (GA/FCS) documentation is initially released or
important changes are made to existing production-level documents.
If you have suggestions for improving this document, send us your comments by email to
doccomments@netapp.com. To help us direct your comments to the correct division, include in the
subject line the product name, version, and operating system.
If you want to be notified automatically when production-level documentation is released or
important changes are made to existing production-level documents, follow Twitter account
@NetAppDoc.
You can also contact us in the following ways:

• NetApp, Inc., 495 East Java Drive, Sunnyvale, CA 94089 U.S.

• Telephone: +1 (408) 822-6000

• Fax: +1 (408) 822-4501

• Support telephone: +1 (888) 463-8277