Subscribe
Accepted Solution

SnapMirror vs SnapVault - setting up DR and Backups

So we have both licenses. We have about twice the storage at the DR site as we do in production in the hopes of keeping snapshots for longer and also writing to tape for archive. Can I set up snapmirror volume and then snapvault on top of it? Or do you have to set up a volume as a snapvault volume, and go back and use snapmirror to make the volume read/write for testing or actual DR situation?

I have the impression snapmirror is better for most things, but snapvault is the only way to keep snapshots for longer than our production snapshots. Is this correct?

Re: SnapMirror vs SnapVault - setting up DR and Backups

I think you are asking about taking a SnapMirror target and SnapVault from it.  To clarify, you can snapmirror and snapvault from the same source... you can cascade volume snapmirror but can't cascade snapvaults (or qtree snapmirror)... but you can vault a mirror or mirror a vault...  When you say snapvault on top of a mirror, that doesn't work since the mirror is read only...but you can vault the mirror copy to another location.

source --> snapmirror target --> snapvault from snapmirror target qtrees to qtrees in a different volume

source --> snapvault target --> snapmirror from snapvault target volume to different volume

In these examples you have to be careful on scheduling so that the mirrors and vaults update at different times.  I would also look at using Protection Manager to handle the workflow. 

Re: SnapMirror vs SnapVault - setting up DR and Backups

Sorry I wasn't very clear. I was wondering if there was a way to use the same storage at the DR site, the same destination volumes even, to snapmirror and then get tons of snapshots (maybe using snapvault) on that that snapmirror destination volume. As in, I was wondering if there was a benefit to using snapvault to hold more snapshots rather than just using normal snapshots on the snapmirror destination volume. I'm closer to that answer via:

https://communities.netapp.com/blogs/vCanuck/2009/01/26/qtrees-and-vmware

http://www.wafl.co.uk/qtree/

http://ocpdba.net/netapp/man/qtree1.htm

Closer but not 100% sure.

My main goal is to get as much out of our storage to hold snapshots at the DR site for as long as possible. Can I just snapmirror and have more snapshots kept at that location vs. our production location?

Re: SnapMirror vs SnapVault - setting up DR and Backups

The only way to do that would be to use Qtree SnapMirror which can have a different retention than the source. With Volume SnapMirror you only can keep the same retention as the source but you can vault from there. VSM has storage efficiency that QSM does not (VSM will send the same dedup source while QSM/SnapVault reconstitute the data then you dedup again on target)

Re: SnapMirror vs SnapVault - setting up DR and Backups

Thanks, that explains it then. I have no qtrees set up, but I may just do my homework on that and see if it will work. One gotcha I read yesterday on qtrees is that if you use NFS for VMware, you can't(?) make the qtrees during production or Vcenter (what about hosts?) will stop seeing the storage for a while unless you set it up a certain way.

Re: SnapMirror vs SnapVault - setting up DR and Backups

About QSM... different efficiency you say. So does it require more bandwidth than regular volume SnapMirror?

Re: SnapMirror vs SnapVault - setting up DR and Backups

A qtree appears as a directory to the host. What documentation says this? Good to know if it is a disruption.

Re: SnapMirror vs SnapVault - setting up DR and Backups

Qsm may need more bandwidth. If The source gets 50% storage efficiency from dedup/compression an then Vsm passes that along in the transfer while qsm does not. Qsm is still block level but doesn't use dedup or compression savings from the source.

There is snapmirror compression that can help reduce bandwidth too.

Re: SnapMirror vs SnapVault - setting up DR and Backups

Well this is that post from 2009, but he says:

https://communities.netapp.com/blogs/vCanuck/2009/01/26/qtrees-and-vmware

One more tip I did discover. If you are creating a NFS datastore for VMware, you have to enable the qtree before mounting it from Virtual Center. Otherwise you receive a rather cryptic “failed to open volume: /VMFS/XXXX” error. Enable the qtree, no need to set any quotas, and try again.