SnapMirror overview

SnapMirror modes

The Data ONTAP SnapMirror feature enables an administrator to mirror Snapshot images either asynchronously or synchronously:

When mirroring asynchronously, SnapMirror replicates Snapshot images from a source volume or qtree to a partner destination volume or qtree, thus replicating source object data on destination objects at regular intervals.
When mirroring synchronously, SnapMirror replicates Snapshot images from a source volume to a partner destination volume at the same time it is written to the source volume.
Additionally, you can configure a synchronous SnapMirror replication to lag behind the source volume by a user-defined number of write operations or milliseconds. This option is useful if you are balancing the need for synchronous mirroring with the performance benefit of asynchronous mirroring.

See Synchronous SnapMirror for more information.

SnapMirror can also be used with traditional volumes and FlexVol volumes. See Effects of FlexVol volumes on SnapMirror replication for more information about using SnapMirror with FlexVol volumes.

Reasons for accessing destination volume information

You can access the information on the destination volume or qtree to

Provide users quick access to mirrored data in the event of a disaster that makes the source volume or qtree unavailable
Update the source to recover from disaster, data corruption (qtrees only), or user error
Archive the data to tape
Balance resource loads
Back up or distribute the data to remote sites

The components of SnapMirror

The basic SnapMirror deployment consists of the following components.

Source volumes or qtrees

SnapMirror source volumes and qtrees are writable data objects whose data is to be replicated. The source volumes and qtrees are the objects normally visible, accessible, and writable by the storage system clients.

Destination volumes or qtrees

The SnapMirror destination volumes and qtrees are read-only objects, usually on a separate system, to which the source volumes and qtrees are replicated. The destination volumes and qtrees are normally accessed by users only when a disaster takes down the source volumes or qtrees and the administrator uses SnapMirror commands to make the replicated data at the destination accessible and writable.

Source to destination to tape variation

A common variation to the basic SnapMirror backup deployment adds a tape backup of the destination volume. By running a tape backup off the SnapMirror destination volume, you do not subject the heavily user-accessed source volume to the performance degradation, system unavailability, and complexity of a direct tape backup.

Source to tape to destination variation

A SnapMirror deployment that supports SnapMirror replication over low-bandwidth connections accommodates an initial mirroring between a source and destination volume via physically transported tape. Once the large-sized base Snapshot replication has been carried out, smaller-sized, incremental Snapshot updates can be carried out over the low-bandwidth connection.

Cascading destinations variation

A variation on the basic SnapMirror deployment and function involves a writable source volume replicated to multiple read-only destinations. The function of this deployment is to make a uniform set of data available on a read-only basis to users from various locations throughout a network and to allow for updating that data uniformly at regular intervals. See Copying from one destination to another in a series (cascading) for more information.

Note
The cascade deployment is supported for SnapMirror volume replication only. It is not supported for SnapMirror qtree replication.

How SnapMirror works

The SnapMirror feature uses the information in the /etc/snapmirror.conf file and the information you enter via the snapmirror.access option or the /etc/snapmirror.allow file to establish a relationship between a specified source volume or qtree that you want to back up, and the destination volume or qtree where the backup is kept.

The SnapMirror feature does the following:

Creates a Snapshot copy of the data on the source volume or qtree
Copies it to the destination, a read-only volume or qtree
Updates the destination to reflect incremental changes on the source, on the schedule you specify

The result of this process is an online, read-only volume or qtree that contains the same data as the source at the time of the most recent update.

What to use SnapMirror for

You might want to copy or use the data stored on a SnapMirror destination if you are in any of the situations described in When to copy volumes. The additional advantages of SnapMirror make it useful in other data retrieval situations, as described in the following table.

Situation	How to use SnapMirror
Disaster recovery You want to provide immediate access to data after a disaster has made a qtree, volume, or system unavailable.	You can make the destination writable so clients can use the same data that was on the source volume the last time data was copied.
Data restoration You want to restore lost data on a qtree or volume source from its mirrored qtree or volume SnapMirror partner.	You can temporarily reverse the roles for the source and destination qtrees or volumes and copy the mirrored information back to its source.
Application testing You want to use an application on a database, but you want to test it on a copy of the database in case the application damages the data.	You can make a copy of the database to be used in the application testing to ensure that the data on the source cannot be lost.
Load balancing A large number of users need read-only access to a qtree or volume.	You can copy the data in a qtree or volume to multiple volumes or storage systems to distribute the load.
Off-loading tape backups You need to reserve all processing and networking resources on a storage system for serving NFS and CIFS requests.	After copying data on the source system, you can back up the data in the destination to tape. This means that the source system does not have to allocate resources for performing backups.
Remote access to data Users who need read access to a volume are distributed over a large geographical area.	You can copy the source volume to other storage systems that are geographically closer to the users. Users accessing a local system can read the data using less resource time than if they connected to a distant system.

Using SnapMirror with SnapDrive^TM software

If you are using SnapDrive software, use SnapMirror to replicate your data. See the SnapDrive Installation and Administration Guide for your version of SnapDrive for more information.

Note
SnapDrive supports the use of volume SnapMirror only. It does not support qtree SnapMirror replication.

Using SnapMirror with MultiStore® software

If you are using MultiStore software, use SnapMirror to migrate or create a disaster recovery vFiler^TM unit. See the MultiStore Management Guide for more information.

Differences between the vol copy command and SnapMirror

The vol copy command and the SnapMirror feature carry out similar functions. They both enable the administrator to copy Snapshot copies of data from a source volume to a destination volume, as long as the volumes are of the same type. When using the vol copy and snapmirror commands, the source and destination volumes must both be traditional volumes or FlexVol volumes. However, these commands differ in several important ways:

The vol copy feature does not require an additional license.
The SnapMirror feature supports automated and scheduled updates of Snapshot data mirrored between the source and destination volumes.
The SnapMirror feature supports incremental Snapshot updates between source and destination volumes.
The SnapMirror feature supports qtree-level replication between the source and destination systems.

Differences between SnapMirror volume replication and qtree replication

You can configure SnapMirror replication for either whole volumes or individual qtrees on a volume.

SnapMirror volume replication

SnapMirror volume replication has the following characteristics:

SnapMirror volume replication can be synchronous or asynchronous.
A destination volume is read-only.
SnapMirror volume replication can only occur with volumes of the same type, that is, both traditional volumes or both FlexVol volumes.
SnapMirror volume replication copies a Snapshot copy of a source volume and all its qtrees to a destination.
A destination volume set up for SnapMirror volume replication must first be set to restricted, read-only status.
SnapMirror volume replication is a block-for-block replication; it transfers the file system verbatim. Therefore, older releases of Data ONTAP cannot understand file system transfers from a later release of Data ONTAP.
Note
See the caution in Prerequisites to running SnapMirror for information about source and destination upgrading order.

SnapMirror qtree replication

SnapMirror qtree replication has the following characteristics:

SnapMirror qtree replication is asynchronous only.
SnapMirror qtree replication occurs between qtrees regardless of the type of volume, traditional or flexible, in which the qtree resides.
SnapMirror qtree replication copies only the contents of an individual qtree to a destination.
If you need to mirror only the data stored on an individual qtree, then SnapMirror replication of that individual qtree uses less disk space on the filer.
A destination qtree is read-only, but the volume on which it is located must be online and writable.
SnapMirror qtree replication can be set up for a maximum of 255 qtrees on any one volume.
SnapMirror qtree replication is a logical replication; all of the files and directories in the source file system are created in the destination file system. Therefore, replication can occur from any release to any release.
Note
If the source file system contains a file type that cannot be represented on the destination file system, the replication will fail. For example, Data ONTAP 7.0 supports files up to 16 TB in size, whereas earlier versions of Data ONTAP support files up to 4 TB. If the source system is running Data ONTAP 7.0, the qtree you want to replicate contains a file greater than 4 TB, and the destination system is running an earlier version of Data ONTAP, the replication will fail.

Differences between qtree SnapMirror and SnapVault

The following are differences between qtree SnapMirror and SnapVault:

Qtree SnapMirror is more likely to be used in an environment requiring an immediate failover capability.
SnapVault is likely to be used with applications that can afford to lose some data (backup) and not require immediate failover.
Due to its heterogeneous capabilities, SnapVault is more likely to be used to protect remote offices.
Qtree SnapMirror does not allow Snapshot creation or deletion on the read-only destination unless the relationship is broken and the destination is brought online. SnapVault adds Snapshot scheduling, retention, and expiration, providing versions (backups) on the destination.
In certain situations, qtree SnapMirror allows replication in both directions because a SnapMirror source and SnapMirror destination can run on the same storage system. SnapVault replicates in one direction; a source and destination cannot run on the same storage system.
Qtree SnapMirror software uses the same software and licensing on the source and destination storage systems. SnapVault software has a SnapVault source system and a SnapVault destination system, which provide different functionality.
SnapMirror transfers can be scheduled as frequently as once every minute. SnapVault transfers can be scheduled once every hour.
Multiple qtrees within the same source volume use one Snapshot copy each on the source system when qtree SnapMirror is used. Only one Snapshot copy total is used when SnapVault software is used.
Qtree SnapMirror Snapshot copies are deleted by qtree SnapMirror software when they are no longer needed for replication purposes. SnapVault Snapshot copies are retained and deleted on a specified schedule.
Qtree SnapMirror relationships can be reversed, allowing the source to be resynchronized with changes made at the destination. SnapVault provides the capability to transfer data from the destination to the source only for restore purposes. The direction of replication cannot be reversed.
Qtree SnapMirror can be used to replicate data between storage systems running Data ONTAP only. SnapVault can be used to back up both NetApp and open systems sources, although the destination storage system must be a NetApp storage system.

Maximum number of simultaneous replication operations

A volume SnapMirror, qtree SnapMirror, or SnapVault replication consists of two operations, one operation being on the source side of the transfer and the other operation being on the destination side of the transfer. Therefore, if a storage system is the source of one replication and the destination of another replication, it uses two replication operations. Likewise, if a storage system is the source and destination of the same replication, it uses two replication operations.

The maximum number of simultaneous replication operations that each storage system model can support is shown in the following table.

Model	Number of simultaneous operations allowed
F85	4
F87	4
F720	4
F740	4
F760	4
F810	8
F820	8
F825	8
F840	16
F880	16
FAS250	4
FAS270	8
FAS920	8
FAS940	16
FAS960	16
FAS980	16
FAS3020	16
FAS3050	16
GF270	8
GF825	8
GF940	16
GF960	16
GF980	16
R100	128
R150	128
R200	128

Storage systems that use ATA drives

Storage systems that have any ATA drives, other than NearStore® systems, have half the maximum number of simultaneous replications that the same storage system has using FC drives. The following table lists the maximum number of simultaneous replication operations for storage systems that can use FC drives and ATA drives.

Model	Maximum number of simultaneous operations allowed (FC drives only)	Maximum number of simultaneous operations allowed (if ATA drives are present)
FAS920	8	4
FAS940	16	8
FAS960	16	8
FAS3020	16	8
FAS3050	16	8

Factors that might reduce the maximum number of operations

A storage system might not reach the maximum number of simultaneous replication operations for the following reasons:

Filer resources, such as CPU usage, memory, disk bandwidth, or network bandwidth, are taken away from SnapMirror or SnapVault operations.
Each storage system in a cluster has the maximum number of simultaneous replication operations listed in the preceeding tables. If a failover occurs, the surviving storage system cannot process more than the maximum number of simultaneous replication operations specified for that storage system. These operations can be ones that were scheduled for the surviving storage system, the failed over storage system, or both. For example, each FAS960 in a cluster can run a maximum of 16 simultaneous replication operations. If one FAS960 fails over to the other, the surviving FAS960 still has a maximum of 16 operations, which can be ones that were scheduled by the surviving FAS960, the failed FAS960, or both.
Note
When planning SnapMirror or SnapVault replications using clusters, take this limitation into consideration.
NearStore systems are optimized as a destination for qtree SnapMirror and SnapVault replication operations. Therefore, the number of simultaneous replication operations shown in the table represents the total number of simultaneous qtree SnapMirror or SnapVault replication operations for which the filer is the destination. Replication operations of which the NearStore system is the qtree SnapMirror source, SnapVault source, volume SnapMirror source, or volume SnapMirror destination count twice against the maximum number.

Example

You have a NearStore system that is the destination of 20 qtree SnapMirror relationships and the source of 5 volume SnapMirror relationships to another storage system. If all the replications occur simultaneously, the NearStore system will have 30 replication operations running concurrently.

How transfers beyond the limit are handled

If more than the allowed number of SnapMirror volume or qtree replications are scheduled to run at the same time, each additional transfer will generate an error message stating that resource limits have been reached. Each transfer beyond the limit will re-attempt to run once per minute until it succeeds, SnapMirror is turned off, or the update is terminated.