FAS to S-series SnapMirror

I have a FAS2050 running 7.3.3. I have a S550 running the latest version possible. I think it's 7.2.xR12.

I want to get my data from my FAS2050 onto my S550 for disaster recovery purposes. I am using SnapManager for Exchange and SQL. I have CIFS and I have LUNs.

I've been told by Netapp that it's not possible. I've been told by people in this community that it is possible.

The person who said that it was possible said that I needed to look towards QSM based replication.

I've never looked at QTREE based snapmirror before, but I assume it just means that you specify a QTREE on the snapmirror command line.



Here is what this looked like when I tried it:

SAN2*> snapmirror initialize -S san0:/vol/cifs_installs_packages/cifs_installs_packages SAN2:/vol/san0_cifs_installs_packages/san0_cifs_installs_packages

***ERROR, unrecognized version 0x78

*ERROR:  License check failed

Fri Sep  3 19:09:11 EDT [snapmirror.dst.err:error]: SnapMirror destination transfer from san0:/vol/cifs_installs_packages/cifs_installs_packages to /vol/san0_cifs_installs_packages/san0_cifs_installs_packages : source qtree does not exist.

Transfer aborted: source qtree does not exist.

Here is what I have for QTREES:
SAN0> qtree
qtree: This command is deprecated; using qtree status.
Volume   Tree     Style Oplocks  Status
-------- -------- ----- -------- ---------
vol0              ntfs  enabled  normal
Xen_LVM           ntfs  enabled  normal
CS007_data          unix  enabled  normal
exchdata          ntfs  enabled  normal
exchlogs          ntfs  enabled  normal
sql_data          ntfs  enabled  normal
sql_logs          ntfs  enabled  normal
sql_SnapInfo_SystemDB          ntfs  enabled  normal
quickbooks_data          ntfs  enabled  normal
PROD_FibreSR_01          unix  enabled  normal
cifs_installs_packages          ntfs  enabled  normal
CS006QB           unix  enabled  normal

Re: FAS to S-series SnapMirror

QSM/SV based will allow you to replicate from any ONTAP version to any other.

But VSM will only allow from lower to higher ONTAP version.

Is 7.1->7.2 and not vice versa.

But within a release family its supported. Like




Re: FAS to S-series SnapMirror

If I remember corrrectly, support was limited to mirror from StoreVaut to FAS but not the other way around (although as you said, it did work but wasn't supported FAS to Storevault).  VSM was the only supported method from the StoreVault GUI... but qtree mirror should work when you run it from the command line (just not supported).

I don't see the reason for the license error...however, the qtree on the target should NOT exist prior to the mirror..the snapmirror command will create the target qtree for you and your syntax does look correct assuming the volume names are correct and the qtree doesn't existing on the target.

We have been upgrading many of the legacy S-Series systems to FAS2020/FAS2040 (2040 preferred since they can run 8.0)...since support is limited and will end soon, I would look at swapping it out unless you don't need support on it.

Re: FAS to S-series SnapMirror

I do see the issue... you don't have a qtree named cifs_installs_packages, but only a volume of that name... if no qtrees on the source, specify /- to specify all source data not in a qtree then specify the qtree target.  For example...

SAN2*> snapmirror initialize -S  san0:/vol/cifs_installs_packages/-    SAN2:/vol/san0_cifs_installs_packages/san0_cifs_installs_packages   # the volume will replicate non-qtree data into a qtree on the target...make sure the san0_cifs_installs_packages volume exists on SAN2.

The license error still doesn't say why...unless the system is not licensed or if it is complaining about using unsupported replication to the storevault.

Re: FAS to S-series SnapMirror

I'm not sure what you're trying to do will work but it's worth trying.  For one that "license check failed" message may be a deal breaker if there is no S-series snapmirror license.

It doesnt look like you actually have any qtrees on that FAS system because the "Tree" column in the output is empty.  Volumes show up in the qtree status output but they are not actually qtrees.  For example, if your volume called cifs_installs_packages had a qtree on it then you would see two lines for that volume in the output, the line you have and a line that would look like this, where this volume has a qtree on it called "whatever":

Volume   Tree     Style Oplocks  Status
-------- -------- ----- -------- ---------

cifs_installs_packages          ntfs  enabled  normal          <-- this entry is for the root of the volume

cifs_installs_packages   whatever       ntfs  enabled  normal          <-- this entry is for a qtree called whatever in that volume

There is a snapmirror trick you can use (that is if snapmirror to s-series even works at all).  If you specify the source of a snapmirror relationships as "/vol/volumename/-"  that is with a trailing "/-" and specify the destination as /vol/volumename/qtreename (this qtree cannot pre-exist) then this means take all the non-qtree data out of /vol/volumename and put it into a qtree called /vol/volumename/qtreename.  The drawback to doing this is that your paths to data will change from /vol/volumename/path to /vol/volumename/qtreename/path on the destination.

After the migration you could mount the path /vol/volumename to some drive letter and then move the data from driveletter:\qtreename\ to driveletter:\   Move not copy and this would be a metadata move and not take too long but theres still an issue with the person doing the move needing to have proper credentials to move all the data.  Most times its easier to just live with having a new path and change your shares.

Make some new dummy volumes and try it first.


Re: FAS to S-series SnapMirror

Almost not sure I need to chime in anymore.... (was chatting about this via email with Adam originally and recommended taking it to the forums)

There is an S-Series snapmirror license...can vouch for that much at least. To check licensing on both systems, just run "licenses" from the commandline.

The Qtree advice sounds spot on -- can't have the qtree exist before, can't have the destination volume restricted (like you have to with VSM), etc.