Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi buddy,
What is the comfort of having a qtree level snapmirror over volume level snapmirror?
Thanks,
Saran
Solved! See The Solution
1 ACCEPTED SOLUTION
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
-Michael
5 REPLIES 5
migration has accepted the solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
-Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
micheal,
I am not able to get the first point.
Thanks
saran
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
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
aggr1/vol/volume1
aggr1/vol/volume2
aggr1/vol/volume/qtree1
aggr1/vol/volume/qtree2
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing usefull info. also the last point I'm not able to get it clearly hence can you make it clearly one more time.
Thanks a lot!
