Fractional reserve effect on snapmirror/vault ?

[saltbartechnologies]

Hello all,

We've recently implemented a newer messaging system based on Exch2007SP2, Win2008, iSCSI, SME6.0, SD6.1 and DoT7.3.2.

We already have mirrors and a snapvault running from the mirror, but after the mailbox migration is complete and studying the regular usage of the system in terms of delta change, I'd like to reclaim the space used by the database volumes. I believe this means taking the tick off of the luns which requires 'space reservation for at least one snapshot', and then shrinking the volumes appropriately.

My query surrounds the effects on both the mirror volumes and the snapvault. Basically if I shrink the source data volume, then will it mess up the block mappings in someway, or invalidate the baseline snapshots that snapmirror and snapvault use?

I know the destination has to be of equal size or greater to get the first initialization going .. but what about changing the vol size after it's been running for a while?

Thanks for any input.

[amiller_1]

If you're doing volume level SnapMirror (VSM), there is an fs_fixed_size volume attribute you have to be aware of when changing volume sizes. With Qtree SnapMirror (VSM) or SnapVault (which is qtree based period), everything is qtree based so changing the volume size won't cause any inherent issues (as long as you have enough space overall of course).

Having said that, I wouldn't recommend shrinking the volume smaller than the LUN -- I'd use a combination of "Space Reclaimer" (SnapDrive function you can schedule inside the Windows VM) and thin provisioning on the NetApp side (uncheck space reserved on the LUN, set volume space reservation to none, enable volume autogrow and snap auto-delete, watch you aggregate free space VERY carefully using Operations Manager).