These are the 2 primary advantages:
- multiple sources cpoied to one destination volume (e.g. to back them up with one backup job instead of 20)
- only parts of the source copied to a destination (for large volumes where you want to snapmirror only a part, e.g. one LUN of 20 in a volume)
It goes a bit deeper than the previous response which is valid.
VSM (Volume SnapMirror) is done at block level. QSM (Qtree SnapMirror) is done at inode level (folder/file).
So lets say you have a volume that looks like the following
If you were to VSM you would copy the whole volume.
But lets say your moving from volume level sharing to qtree level sharing where you can make better use of quotas or you have purchased more larger capacity disks and created a 64bit aggr etc.
To move the above you would;
QSM the the following;
qsm vol/volume/qtree1 to new aggr1/vol/volume/newqtree
qsm vol/volume/qtree2 to new aggr2/vol.volume2/newqtree
Then your could qsm the the remaining volumes using the /- option of qsm ( this can also be used to qsm luns in volumes to placing them within a qtree.
qsm vol/volume1/- to new aggr/vol/volume/newqtree
qsm vol/volume2/- to new aggr/vol/volume2/newqtree
Another thing to remember that if your moving from 32bit aggrs to 64bit aggrs (OnTap 8.01) then QSM will allow you to migrate from 32 to 64 bit aggrs where as you cannot use VSM to migrate 32bit aggr to 64bit.
VSM migrate will take NFS offline whilst it migrates the volume. Qtree has no affect on the NFS service.
VSM is faster
QSM is much slower, but when you quiese and break your snapmirror, the source remains online but READ_ONLY! which is great as you have an exact copy of your data as a backup and helps convoince the managemnt that your change will not lose data!
Hope this helps.
The "/-" option with QSM is very useful to know as we were looking at options available to migrate legacy data residing at the volume level over to Qtrees on flex vols.
Thanks for this useful tip