SMVI Backups Implementation

[ Edited ]

Well I have read and read to the point that I THINK I know how theoretically SMVI Backups should work.  BUT in to be completely honest Im not sure that the way it was configured in my environment is the most efficient one.  We have several backup jobs pointing to each of my VMware Datastores.  The thing is while analizing the logs I noticed that each time a backup starts it list the machines is going to backup (the ones in that data store) and in many cases the area repeated on each job, because those virtual machines have vdisks in several different datastores. 


How should I have this configured?  One single backup job with all the datastores in it?  If I do that and select to start the snapmirror update process will that trigger SM for all the volumes?  Im relly confused with this product, specially with the new version

Re: SMVI Backups Implementation

no one has seen the mythical Snapmanager for Virtual Infrastructure working on a Multidatastore environment?

Re: SMVI Backups Implementation

I "inherited" an SMVI system. We basically backup every VM in a single job. It mostly works OK. However, we did turn off the "VMware consistent snapshot" across the board because it was causing too many problems - so we're getting "crash consistent" backups. We backup our databases seperately to a CIFS share using Oracle RMAN and whatever SQL's equivalent is called. Each job backs up somewhere between 20 and 50 datastores. We store databases and page/file/temp data on different datastores, and they are excluded from backups, so we're really just backing up the O/S and application executables and configs.

If I were to redesign this environment from scratch, I'd probably tend towards one backup job per O/S datastore (the VM's C:\ drive) + "partner" application datastore (the VM's D:\ drive).

Re: SMVI Backups Implementation

If I do that and select to start the snapmirror update process will that trigger SM for all the volumes?

yes it will.

the default behaviour for a job pointing to datastores is like this:

it will lookup the VMs in this datastore. if it finds VMs with VMDKs on other datastores it will automatically include these other datastores in the job, and it will create snapshots and snapmirror updates on these additional datastores too (I think this is called 'spanned entities' in VSC 4).

so if you have a lot of VMs which are distributed randomly over datastores, then do one job for all of them. otherwise you will find a lot of snapshots on the volumes from all the different backup jobs.

if you have a system how the VMDKs are distributed (i.e. one datastore for system drives and one for datadrives), then group those datastores in one job and make a job for each group.