2012-09-12 11:38 AM
This may be a dumb question.. Can I turn off the "nosnap=on" option in one of our aggregate? I have one aggregate that is showing that option. We don't take a snapshot of the aggregate and I want all our aggregates to be uniform in settings. What impact would turning that option bring?
2012-09-12 01:03 PM
If you are sure you don't want the aggr snapshots, you can surely use the options(nosnap=on), but the best practice is if it is root volume, please make sure the aggregate snapshots occur atleast once a day and snap reserve on the aggregate can be minimum to 5%.
If you have snapmirror enabled on the volumes of the aggr (referred), it is safe to set nosnap to on.
2012-09-12 01:08 PM
The fact that only one of our aggregates have that option means most of our aggregates has aggregate snapshot capability on.
I just want to know if turning nosnap to off will do any harm on the aggregate.
2012-09-13 05:06 AM
Most customers didn't notice the change but do notice more the larger size of root needed for 8.x Agreed the Root aggr reserve is 0 and non root have an aggr reserve on new installs. Haven't heard a best practice either to use aggr snaps or a reserve on root. There could be a conflicting doc or kb out there that would be good to see if it does mention that.
I like keeping a snapmirror of the root volume local on a system with more than one aggr then that mirror can be broken and marked as root if root ever fails. A Remote copy is good too. Similar to what we do with vsroot load sharing mirrors in Cluster-mode and works well for vol0 in 7-mode too. If you have he space though since larger in 7-mode for a whole root volume as opposed to a 20mb mroot
2012-09-13 05:20 AM
Unless you need different retention why not snapmirror? For as little as root changes except for logs mirror with local snaps fits the ticket. I leave new installs with 0 on root aggr reserve but am interested if a doc does say not too. Best practice is 0 now on a dedicated root aggr. But lots of kbs and docs out there.