Snapvault & VMware volume

[dailyfresh]

Hello,

I have a couple of volumes on which vm's reside. We choose to do so to make maximum use of deduplication a volume.These volumes are snapvaulted to an external location from a FAS2040 to a FAS2020. Al worked fine. Both the volumes grow and due to bandwidth limitations the snapvault process isn't done during a cycle. The lag is growing.

Upgrade bandwidth would be the best solution. On the other hand I was wondering whether we have chosen the right approach? Would it be a better config to place each VM on it's on volume, for instance? Would not solve this, but I was just wondering how you guys are managing such an environment. Our swap and pagefiles are on a other disk on another volume which is not snapvaulted.

[merick]

Unfortunately SnapVault is file based replication, and as such it is unaware of things like dedup. I am not sure what your long term retention requirements are, but if they are not too steep you may want to think about using SnapMirror. SnapMirror is dedup aware, and you can enable compression on the WAN transfer. If you are not licensed for SnapMirror, or you have longer retention requirements you may want to try staggering your SnapVault schedules if the business would permit it. As an example run 1 VM datastore backup on MWF and the other on TThSa.

Thanks,

Erick

[dailyfresh]

Never looked into snapmirror before. I see now that we do have licenses on both filers. See it would be an option to figure out how we could make use of snapmirror and how to implement it.

Do you know where the max of long term retention is or why long term retention requirements are important when using snapmirror?

[merick · Accepted solution]

The primary use for SnapMirror is disaster recovery, and the primary use case for SnapVault is backup/archive. With SnapMirror you will have a 1-1 relationship with source and destination, i.e. if you mirror once per day, and keep 30 days, you will have 30 snapshots at both the source and destination. If you compare that to SnapVault you may maintain different schedules, and different retention policies at source and destination. So as an example you may have once a day snapshots at your primary for 30 days, but then at secondary also keep those monthly's for 12 months. In that case you would have 30 snaps at primary, and 42 at your secondary. A lot of our customers mirror and then vault if they need to keep the data for a long term.

You are free to keep snapshots in a volume for as long as you'd like as long as you have the space. This is the same with SnapVault or SnapMirror. Here is our best practice guide for SnapMirror: http://www.netapp.com/us/media/tr-3446.pdf

[dailyfresh]

Hence the 'mirror' part in the word 'snapmirror' . Thanks for your explanation. I downloaded the PDF and will study it.

We snapvault all qtrees. This is once setup with snapvault cause of the backup/archiving part. All well for office documents, etc. But also the VMFS volumes are being snapvaulted. Besides the long sync -  because snapvault is filebased and unaware of dedup - I now make the assumption it isn't as quick up and running in cause of emergency as when you snapmirror it?

Question which comes to mind: should we not snapmirror the VMFF5 volumes, so that VM's are up and running in no-time, and snapvault those snapmirrored volumes for backup/archiving purposes?

[merick]

You can mirror more frequently than you can vault, and because SnapMirror is dedup aware, and supports compression, you will most likely be able to push the data over the wire faster than you would with SnapVault. If you want to get data at your DR side online as quickly as possible, yes, use SnapMirror. Setup a SnapMirror relationship using OnCommand System Manager to mirror your VMFS datastores. Then leverage the VSC (Virtual Storage Console) to automatically trigger a snap and replicate to your DR location at a scheduled time.