BE 2012 Multithreaded VMWare Backups?

[bigwheat]

I am running Backup Exec 2012 (14.0 rev 1798) and attempting to backup 8 virtual machines from vCenter (v 5.0). I am writing the backup to a deduplication folder. It appears that the job is backing up the servers sequentially - one at a time. Is that how this works? I'm assuming I'm missing something as this would be far too slow to backup any environment with more than just a handful of vm's. How do I make the backup run against multiple vm's at the same time ?

[pkh]

The only way you can backup multiple VM's at the same time is to use multiple jobs.  Within a job, the VM's are backed up sequentially.

Running jobs concurrently does not necessarily mean that the overall time would be reduced.  The jobs would be contending with each other for resources.  This applies to all jobs, regardless of whether they are using dedup or not.  If you take a look at the resource requirements for the dedup option, you can surmise that dedup operation is very resource intensive, especially on the media server.

[bigwheat]

Thanks for your response. I can only add a VMware server to the server list one time - it can't be there multiple times. So within that server, I have to create multiple jobs - and I can schedule them at the same time. 

For us, the time would be reduced greatly running jobs sequentially. Maybe not in everyone's environment, but I have to think that anyone with any decent sized virtual environment would not be able to run jobs sequentially. With 30, 50, 100+ virtual machines, running sequentially would not be feasible. I'm not sure I understand Symantec's thinking in doing it that way. If I were able to setup the backups to run in one job, I could make sure that Symantec picks up any new server automatically - a feature they mention in multiple places. It's also going to be much harder to manage.

We've been a Symantec Backup Exec customer (and Veritas) for years. With 2012, Symantec has made a push marketing wise that they are taking care of the virtual environment shops, but I'm not feeling it. This may be the final push to a different product for us.

As far as concurrent jobs overall - I can't imagine that any shop doesn't run jobs concurrently. Yes, you have to take into consideration your limits, but anybody with more than a few machines, physical or vitual, can't have a viable backup solution if it only runs sequentially.

[pkh]

You can put this up as an suggestion for improvement in the Ideas section.  If there are enough users who agree with you, this might get incorporated as a feature in some future release of BE.

[Ralf_Gerresheim]

I  agree with bigwheat. For medium-sized or bigger environments it is necessary, to run more jobs concurrently. Even the VMware solution is able to run up to 8 backups simultaneously.

One possible solution perhaps is to set up the backups from the hosts and not fro the virtual center. The disadvantage is that you gat an error message of missing servers in the job, when the virtual server moves to another host.

It would be good:

- if the software allows for simultaneous backups of virtual machines
  Nice, if the number of parallel backups could be set in the job or on a generall settings page. This allows
  for adjustment of local ressources (bandwidth, backup-device, etc)

- if allowed, the software has a built-in intelligence to share the parallel backups to the virtualization hosts
  i.e. running one backup on each host, or decide on workload of host who performs more backups at the 
  same time ...

[teiva-boy]

Other products can backup multiple VM's simultaneously.  I wonder if this is yet another artifical limitation put into BackupExec?  

You've got Netbackup, Avamar, Networker, and I think even Commvault all can do multiplle VM's concurrently.  Limited by your storage speed and IOPS.  It's intensive to create the snap, read the snap, and clean up the snaps.  Not to mention CBT has its own overhead.

[Colin_Weaver]

Just for info what you ask for is not specifically a 2012 limitation, 2010 also sequentially backs up VMs unless you create separate jobs.