What is SnapMirror?

SnapMirror is a feature that enables us to replicate data. You can replicate data from specified source volume or qtree to another destination. The destination can be on the same filer, or it can be in complete other location as long as there is a connection between source and destination.

There are three modes availabe:

• SnapMirror Sync – replicated data to the destination ASAP – so basically when data is written to the source volume it is being replicated instantly.
• SnapMirror Semi-Sync – The lag between source and destination is maximum 10 seconds. This mode give us better performance compared to sync mode, and still RPO (Recovery Point Objective) is close to be zero.
• SnapMirror Async – I would say this is the one you will probably meet the most. The snapmirror is being updated based on the schedule, it can be updated as often as every minute, or once a month. This mode I will focus on in this post.

 How does SnapMirror work?

SnapMirrors task is to replicate the data from a source volume (or qtree!) to a partner destination volume (or qtree). Before using SnapMirror you have to establish a relationship between the source and the destination.
In case of SnapMirror Async you have to set up the schedule that goes to /etc/snapmirror.conf file on the destination filer/vfiler. Well – by definition you do not have to setup the schedule, but without the schedule the relationship will never get updated as long as storage admin will not update it manually.
So – how SnapMirror works when the relationship is initialized:

1. Creates a Snapshot copy of the data on the surce volume
2. Copies it to the destination, which can be a read-only volume or qtree
3. Source and destination share the common snapshot.

As you can notice, when the relationship is initlized for the first time, step 2 is transferring all the data, in other words it is base-line copy.

How SnapMirror works when the relationship is already initialized and the update is executed:

1. Create a Snapshot copy of the data on the source volume
2. Compare the new Snapshot with the last common snapshot copy between the source and the destination
3. Transfer to destination only the data that has changed since the last update

 Let’s set up of the Volume SnapMirror a-sync relationship

Step 1.  Add a proper licence to both source and destination filer:

filerA> license add xxxyyy
filerB> license add xxxyyy

Step 2. Turn on the SnapMirror

filerA> options snapmirror.enable on
filerB> options snapmirror.enable on

Step 3. Allow the access on the source (snapmirror.allow vs snapmirror.access)

filerA> options snapmirror.access host=filerB

Step 4. Create a source and a destination volume

filerA> vol create sourcevol aggr1 50g
filerB> vol create destvol aggr1 50g

Step 5. Restrict the destination volume (the destinatnio volume has to be restricted)

filerB> vol restrict destvol

Step 6. Initialize the snapmirror

filerB> snapmirror initialize -S filerA:sourcevol filerB:destvol
Transfer started.
Monitor progress with ‘snapmirror status’ or the snapmirror log.

Step 7. Check the status. If it’s empty volume the initialization shoud go really fast so after a minute or two you can see

filerB> snapmirror status
Snapmirror is on.
Source              Destination      State         Lag    Status
filerA:sourcevol    filerB:destvol   Snapmirrored   00:00:45   Idle

Step 8. Setup the snapmirror schedule

The snapmirror schedule has to be setup on the destination volume (/etc/snapmirror.conf)

The syntax of the schedule is:

src_system :/vol/src_vol[/src_qtree] dest_system :/vol/dest_vol[/dest_qtree] arguments schedule

Simple example, which will update the snapmirror relationship at 10 a.m. every Monday, Wednesday and Friday would be:

filerB>rdfile /etc/snapmirror.conf

filerA:sourcevol  filerB:destvol – 0 10 * 1,3,5

Summary

SnapMirror is a complex technology. In this post I presented only the most simple setup of asynchronus Volume Snapmirror. If you would like to go a little bit deeper into how the transfer works, how to setup the QSM or what arguments can you specify try this book:
Data Protection Online Backup and Recovery Guide

To set a SnapMirror relationship between source filer and destination filer you have to allow the destination to pull from source. In other words  the source filer has to allow the destination filer to replicate the data from the entire volume/qtree. There are basically two ways to do it:

snapmirror.access

snapmirror.access is an option that let us provide the list of the filers that have a permission to pull the data from the source filer. To print the current setting just go with:

filerA>options snapmirror.access
snapmirror.access   host=filerB,filerC AND if=vif-10,vif-11

What does it mean? It means that filerB, and filerC has an access (as SnapMirror Destination) to pull data from SnapMirror Source volume/qtrees. The data can be accessed only by the network interfaces vif-10, and vif-11 (again – it is just an example).

If you would like to set it up by yourself, you can just go with:

filerA>options snapmirror.access host=filerC,10.12.12.13
filerA>
filerA>options snapmirror.access
snapmirror.access host=filerC,10.12.12.13
 

snapmirror.allow

snapmirror.allow is a file. The location of the file is /etc/snapmirror.allow and it can be edited with your favorite  wrfile command :). The syntax of the file is pretty simple:

filerA>rdfile /etc/snapmirror.allow

filerB
FilerC

But there is one trick. If you would like to use snapmirror.allow you have to set the snapmirror.access option, because this is the first thing that is checked.

filerA>options snapmirror.access legacy

If the snapmirror.access is not set to legacy option, the filer will not check the snapmirror.allow file at all.

Troubleshoot the access

The first thing would be to check if a proper license is installed on both source and destination, but I’m sure you already checked that.
If you use the host-name instead of IP – make sure that the filer can resolve the name and the host is reachable, the easiest way is to ping it:

filerA>ping filerC
filerC is alive

If you can ping the host by IP but not by the host-name, make sure the filer can resolve the name (check /etc/nsswitch.conf and optionally /etc/hosts).