Subscribe

SnapMirror'ing compatibility

According to NetApp, the destination filer should have the highest version of Data OnTap.

The source filer should always be the same or lower version of Data OnTap.

When our R200 was upgraded to 7.2.5.1, it was qtree snapmirroring its vol0 to the R150 (Data OnTap 7.0.7) and caused it to panic, so we broke the snapmirror replationship and it is fine now.

Why is it then that FAS3020's with 7.2.4/7.2.5.1 are qtree snapmirroring their vol0's to the R150 without any panic issues?

Based on the results from R200, it should not work, but it does.

The only difference I can find is that it is a R200 and the other filers are FAS3020 models.

We can see that for some reason the R200 being on 7.2.5.1 is non-compatible with snapmirroring to a R150 on 7.0.7.

But, when a FAS3020 is on 7.2.4/7.2.5.1 it is compatible with snapmirroring to a R150 on 7.0.7.

Any ideas or suggestions as to why this can work like this?

Re: SnapMirror'ing compatibility

My guess would be that the versions are to far appart. 7.2.4 to 7.2.5.1 is only a mirror point release upgrade. 7.0.7 to 7.2.5.1 is a large step. What does the upgrade adviser recommend on the now site?

http://now.netapp.com/NOW/knowledge/docs/ontap/rel73/html/ontap/upgrade/upgrading/task/t_oc_upg_before-upgrade-advisor.html

http://now.netapp.com/NOW/products/interoperability/

http://now.netapp.com/NOW/cgi-bin/relcmp.on

Re: SnapMirror'ing compatibility

I'm not sure if this will help or not, but here's how it works.

When SnapMirroring between major releases (where major release is a single dot release, so 7.0 <-> 7.2 would be crossing a major release while 7.2.3 <-> 7.2.5.1 would not):

o For Volume SnapMirror, the destination must be higher than the source. This means that you cannot resync back to the lower release after a break. The code will stop you from even attempting it.

o For Qtree SnapMirror, the rules are a bit looser and a bit more vague. The destination can be lower, unless you are using a specific WAFL feature in source

that is not available in the destination (e.g. a qtree on the destination is larger than an allowed volume on the source, or a higher # of files or maxdirsize, etc.).

So it works in general, but won't in specific cases. I don't believe the code will stop you from trying it though.