snapmirror

snapmirror.allow and snapmirror.access

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).

SnapVault vs SnapMirror – what is the difference?

When I was getting into NetApp  I had a big trouble understanding the difference between snapvault and snapmirror. I heard an explanation: Snapvault is a backup solution where snapmirror is a DR solution. And all I could do was say ‘ooh, ok’ still not fully understanding the difference…

The first idea that poped out to my head was that snapmirror is mainly set on volume level, where snapvault is on qtree level. But that is not always the case, you can easily setup QSM (Qtree snapmirror).

The key to understanding the difference is really understand the sentence: Snapvault is a backup solution where snapmirror is a DR solution.

What does it mean that SnapVault is a backup solution?
Let me bring some picture to help me explain:

SnapVault

SnapVault

Example has few assumptions:

  • we’ve got filerA in one location and filerB in other location
  • that customer has a connection to both filerA and FilerB, although all shares to customers are available from filerA (via CIFS, NFS, iSCSI or FC)
  • all customer data is being transfered to the filerB via Snapvault

What we can do with snapvault?

  • as a backup solution, we can have a longer snapshot retention time on filerB, so more historic data will be available on filerB, if filerB has slower disks, this solution is smart, because slower disk = cheaper disks, and there is no need to use 15k rpm disk on filer that is not serving data to the customer.
  •  if customer has an network connection and access to shares on filerB he can by himself restore some data to filerA, even single files
  • if there is a disaster within filerA and we loose all data we can restore the data from filerB

What we cannot do with snapvault?

  • in case of an disaster within filerA we cannot “set” filerB as a production side. We cannot “revert the relationship” making the qtree on filerB as a source, and make them read/write. They are snapvault destinations so they are read-only.
  • (having snapmirror license available on filerB we can convert Snapvault qtree to snapmirror qtree which solves that ‘issue’)

What does it mean that SnapMirror is a DR solution?
Again, let me bring the small picture to help me explain:

SnapMirror

SnapMirror

Example has few assumptions:

  • we’ve got filerA in one location and filerB in other location
  • that customer has a connection to both filerA and FilerB, although all shares to customers are available from filerA
  • all customer data is being transfered to the filerB via snapmirror

What we can do with snapmirror?

  •  as a backup solution we can restore the accidentally deleted, or lost data on filerA,  if the snapmirror relationship has not been updated meantime
  • if there is some kind or issue with filerA (from a network problem, to a total disaster) we can easily reverse the relationship. We can make the volume or qtree on filerB, as a source, and make it read-write, provide an network connection to the customer and voila – we are back online! After the issue has been solved we can resync the original source with changes made at the destination and reverse the relationship again.

To sum up

This is not the only difference between snapmirror and snpavault. But I would say this is the main one. Some other differences are that snapmirror can be actually in sync or semi-sync mode. The async mode can be updated even once a minute. Where the snapvault relationship cannot be updated more often then once an hour. If we have few qtrees on the same volume with SV they share the same schedule, while with QSM they can have different schedules, etc.. 😉

If you would like to know more check out this document: SnapVault Best Practices Guide
Data Protection Online Backup and Recovery Guide