Multiple SMVI schedules for same volume?

[MSEBEL1980]

We're wanting to do multiple schedules with different retention for our volumes through SMVI. It appears that, at least with the GUI, you can only specify one type of schedule be it hourly, daily, etc with a single retention count. If we want to do only 14 daily's and then 8 weekly's, it appears we need to have two separate backup jobs for the same volume with those respective settings. This is obviously different than the options you get by doing using the "snap sched" at the command line of the filer.

Can anyone see any issues that would arise by having these different jobs for a single volume? Has anyone implemented a setup similar to this in their environment?

Thanks for any input!
Matt

[keitha]

This is a pretty common practice with SMVI. Just be sure to name your backup jobs differently to prevent snapshot name collision and you are good to go...

Keith

[MSEBEL1980]

Thanks for the answer, Keith. Here's what we're thinking of doing:

Two SMVI schedules for vm-vol1:

• vm-vol1-daily - set schedule to Weekly and run on Mon-Sat @ 1am - Retention set to 12
• vm-vol1-weekly - set schedule to Weekly and run on Sun @ 1am - Retention set to 8

Is this in line for what you're seeing other users do?

[wduvall02]

That's exactly what we do. I think you may have a typo on your daily job though as the schedule should be set to Daily instead of Weekly?

[MSEBEL1980]

Actually, no that's not a typo because what we're thinking of doing is taking the "Weekly" option and carving it up into two backup jobs where our "daily" job has Mon-Sat selected and then our "weekly" job has only Sunday selected. What we're thinking here is that because the actual "Daily" option is setup to do it every day, that when we took our "weekly" backup on Sunday, there would be two backups on that same day. Because the SMVI jobs don't seem to work like the automatic schedule where, on Sunday only the weekly will run, we're trying to accomplish the same thing.

Does that make sense? Was this something you thought of earlier but there ended up being reasons not to do it that way?

[keitha]

Glad I could help. You are right on about using the weekly schedule and selecting multiple days to prevent duplicate backups on the same days. A couple of things for you to consider though;     1. Do you have snapshot auto delete turned on? If so and snapshots get deleted you will have to manually reconcile the actual snapshots with the SMVI inventory. Just a heads up.     2. Any chance you will run these jobs "on demand"? If you do keep in mind if you do a number of backups value it will trim the oldest snapshot leaving you with potentially less than 8 weeks of backups. That is, if you ran the daily one a few extra times before a change then it will shorten the actual retention. You may want to use the number of days value instead if you need a certain amount of time.    3. 8 weeks is quite a long retention. Be sure to dedupe before the backups occur and be very careful with things like storage VMotion that can generate large amounts of changed data. Also keep in mind that a storage VMotion or a VM delete will not yield any space until the 8 weeks pass.   Keith

[MSEBEL1980]

Keith,

Thanks for the extra input.

We have auto-delete disabled and are counting on SMVI to handle the retention of the snaps, but that's great advice that we'll have to remember in the future.

Yes, we will likely run "on demand" jobs in the future. I've already set the retention to go off of number of days instead of count since I figured that was going to happen and going by count would end up whacking out some of the scheduled snaps.

And yes, 8 weeks is quite a while especially to keep in the primary volume but this is what our management is wanting us to try and then report some numbers back to them. We have been trying to design around using the SV-SMVI process and vaulting that stuff to SATA, but for some reason we're getting some doubts from others on whether that will really work for us in the long run.

[keitha]

I have set up several environments using the SV-SMVI tool and it works well. The biggest complaints are the fact the restores from the vault are manual and the SnapVault transfers are not really monitored.

Here is another idea for you. Perhaps you use VSC for the daily backup while you use SnapCreator for the weekly backups and the Vaults. The newest version of SnapCreator supports SnapVault and has a "Mount" capability that will make restoring from the Vault easier. Together you will get the vCenter integration and the Automated SnapVault capability. The downside is of course it is 2 separate tools... Still food for thought.

Keith

[MSEBEL1980]

Keith,

I started to look at SnapCreator just the other day. Can you give me a quick idea on how you've implemented the SV-SMVI jobs within SnapCreator?

[keitha]

No need! SnapCreator has native SnapVault integration! One of the great things about it!

[MSEBEL1980]

Yeah, I have the same complaints about SV-SMVI that you're hearing as well. The restores really seem to be the biggest pain especially for thin-provisioned vm's. Because the the SnapVault process is file-level and copies the vmdk's outside of the hypervisor, it blows them out to their -flat versions. The only way to get them back and usable by the hypervisor is to do a command line import process from the snapvault snapshot back through the hypervisor to the NFS filesystem. Pretty messy if you ask me unless there's an easier way to do it we aren't aware of.

Thanks for the advice on the SnapCreator. We'll have to look into that and see if that make sense for our environment.

Have you seen anyone start to think about also enabling compression on their SnapVault's? We've started to investigate this as another space savings tool when talking about all the duplicate copies of data within the SnapVault.

[keitha]

I actually haven't seen the results of Compression yet but that is a perfect use for it. If you set it up, let us know how much you save!

[MSEBEL1980]

Will do. We actually need to get up to 8.1.x before we can do some of the more advanced compression options like inline compression as those options aren't available in 8.0.2.