Replication in NetApp Clustered Data ONTAP

By on 04/06/2015.

cDOT 8.3 codename was 'FullSteam'

cDOT 8.3 codename was ‘FullSteam’

Data protection is one of the most critical aspects of any storage infrastructure. When data is lost it almost always translates directly into money lost and time lost.  For storage administrators, this means that providing protection is arguably the most important task that you have.  If you are in a regulated industry, such as banking or health care, this is even more true in order to ensure compliance is adhered to, and avoid those nice visits from your friendly auditor.

NetApp clustered Data ONTAP (cDOT) has had two primary data protection mechanisms …

  1. SnapMirror
  2. SnapVault

I’m deliberately not mentioning Snapshots here because, while they are critical to providing point-in-time recoverability, they can only do so on the local volume.  If the aggregate fails, so do the SnapShots, which means you have lost data.  For this post, I am going to focus on replication technology that protects against failure of the primary data location.

SnapMirror is targeted at disaster recovery of the source volume.  In the event of failure, the destination is made writeable, at which point the clients can re-connect and resume operations.  When the original source is recovered, the mirror relationship can be reversed to provide ongoing protection, or to migrate clients back without data loss.

SnapVault is targeted at backup and archive.  Data is replicated and snapshots are taken at the destination with the intention of being kept for a longer period of time, allowing the restoration of individual files and LUNs quickly and easily from the destination to the source.  A SnapVault destination volume cannot be made writeable for disaster recovery purposes.


With the release of cDOT 8.3 there have been some changes in these two protection functions:

  • SnapMirror and SnapVault transfers can be compressed over the network. This saves network bandwidth and space on the destination volume.
  • Version-flexible SnapMirror removes the restriction to have the destination NetApp use the same, or higher, version of Data ONTAP. With version-flexible SnapMirror, performing rolling updates of Data ONTAP across the enterprise is significantly easier by relaxing the rigorous order that was previously necessary.
  • SnapMirror and SnapVault to the same destination volume. Previously this would require different volumes, leading to potentially significant additional capacity being needed.  Using this relationship type, both operations can target the same destination.

Let’s look at some of the fundamentals behind SnapMirror and SnapVault configuration, and explore the new features and how they are different.

SnapMirror Policies

cDOT relies on polices to dictate how many snapshots need to be retained and/or replicated as a part of the relationship.  Additionally, the policy contributes to determining the type of relationship that exists between the source and destination.  In versions of cDOT prior to 8.3, there are two types of policy:

  1. async-mirror – This is a standard SnapMirror relationship which asynchronously mirrors data from source to destination using the block replication engine. The default example for this type of policy is DPDefault, which can be viewed using the command snapmirror policy show -policy DPDefault -instance.sully2_pic_1There are three things that we want to note here:
    • The policy type is set to async-mirror
    • The Create Snapshot value is true
    • There is a single rule, “sm_created” with a retention policy of 1

    This means that the SnapMirror engine will create a snapshot (using the standard SnapMiror naming policy), then replicate the difference between the new SnapMirror snapshot and the previous one (if the relationship is being initialized, then a snapshot will be taken and everything before it will be replicated).  After the update is complete, the older snapshot will be deleted leaving just one SnapMirorr snapshot in place.

  2. vault – This is the traditional SnapVault relationship, relying on the logical replication engine to asynchronously replicate data from source to destination. The default example policy for this type is XDPDefault, and it can be viewed the same way as before.sully2_pic_2Just as above, there are three things to note:
    • Policy type is set to vault
    • The Create Snapshot value is false
    • There are two rules, “daily” and “weekly”, retaining 7 and 52 snapshots respectively.

    This default SnapVault policy will not create any snapshots when an update is triggered.  Instead, it will replicate any existing snapshots which have names matching the patterns in the “SnapMirror Label” column (“daily” and “weekly” in this instance).  If you are using the standard cDOT scheduled snapshots, then they will automatically use names such as “daily.0”, “daily.1”, “daily.2”, and “weekly.0”, “weekly.1” to denote the frequency of the snapshot and how old it is.  This policy will keep one week of daily snapshots and one year of weekly snapshots of your protected volume at the destination.


Clustered Data ONTAP 8.3 introduced a new type of policy which allows us to take advantage of both SnapMirror (disaster recovery) and SnapVault (backup and archive) functionality targeted at the same destination volume.  This hybrid protection policy uses the type mirror-vault and relies on the logical replication engine as well.  The default policy created with this type is MirrorAndVault, which is shown below.


Let’s look at the same three things as before:

  • The policy type is mirror-vault
  • Create snapshot is true
  • There are three rules, one to create a snapshot (using the standard SnapMirror naming policy), one for “daily” snapshots which already exist, and one for “weekly” snapshots which already exist.

Like a normal SnapMirror relationship, the first rule will create a snapshot and replicate any differences between it and the previous SnapMirror snapshot.  However, the latter two rules make the replication engine behave like a SnapVault relationship and will cause snapshots with “daily” and “weekly” in the name to be replicated, and kept, as well.

SnapMirror Relationship

By combining the relationship type, set when first creating the SnapMirror, and the policy type selected above we are affecting the type of transfer that is happening.


There are two values that we are concerned with when creating a SnapMirror:

  1. DP – A standard data protection relationship type, used for SnapMirror. This relationship type requires a policy with type of async-mirror.
  2. XDP – An extended data protection relationship type, used for Snapvault. This relationship, prior to cDOT 8.3, was used for SnapVault in conjunction with a policy type of vault.

In cDOT 8.3, the XDP relationship type and the async-mirror, or MirrorAndVault, policy types are combined to create a version-flexible SnapMirror relationship.  This uses the logical replication engine to create a relationship which is not tied to SnapMirror version.

Let’s look at a summary table of SnapMirror relationship type and policy type.

Relationship Type Policy Type Result
DP async-mirror Standard SnapMirror
DP MirrorAndVault Incompatible
DP vault Incompatible
XDP async-mirror Version Flexible SnapMirror
XDP MirrorAndVault Version Flexible SnapMirror
XDP vault Standard SnapVault

Creating a version-flexible SnapMirror relationship can be done using the new on-box System Manager or through the command line.  For System Manager, simply check the box to specify a version-flexible mirror.


From the command line, simply create an XDP relationship and use an async-mirror or MirrorAndVault policy type.

snapmirror create -source-path vserver:volumeName -destination-path cluster://vserver/volumeName -type XDP  -policy DPDefault

Other New Features

Lastly, let’s talk a bit about a bit of two overlooked features.

If you are a user of FlexClone to create test and development environments, then sometimes you know that those “accidentially” become production. Previously, in order to protect those FlexCloned volumes you had to do a full split. As of cDOT 8.3, that is no longer the case, you can mirror a FlexClone to provide protection to all of your data.

With cDOT 8.3, SnapMirror and SnapVault policies can have network compression enabled, which, as the name implies, compresses the data as it’s being sent across the network.  This reduces the amount of bandwidth needed, potentially speeding up replication times.  Enabling the feature is trivial, simply modify the SnapMirror policy being used:

snapmirror policy modify -policy DPDefault -is-network-compression-enabled true

SnapMirror and SnapVault remain core to providing data protection for your organization.  Whether you are protecting against disaster or simply want to provide a disk-to-disk backup mechanism that can take advantage of all the storage efficiency and data access methods of Data ONTAP, SnapMirror and SnapVault can meet those needs.

If you’re interested in more information on SnapMirror and/or SnapVault, I highly recommend these sources:

Andrew Sullivan
Andrew has worked in the information technology industry for over 10 years, with a rich history of database development, DevOps experience, and virtualization. He is currently focused on storage and virtualization automation, and driving simplicity into everyday workflows.