vRanger and VEEAM: Scale Issues

16 09 2010

 

I manage the backups for about 400+ vms on a daily basis.  We are using a mix of vRanger and VEEAM to backup our vms both at our main site, and at a couple of smaller branch sites.  We use vRanger for our main site and VEAAM for the branch sites.  As far as features, vRanger and VEEAM have flip-flopped in the past, with VEEAM usually taking the lead and vRanger following suit 6 months to a year later with certain features (CBT support for instance).  The main differentiator that caused us to choose one over the other for the our production site is SCALE.

vRanger is our choice for VM backups in our production site.  As we must fit all 400 of these backups into reasonable backup windows, we are using the limits available for tasks running per datastore, host, and backup Groups.  By using jobs based on backup groups composed of small numbers of hosts, we dont have to constantly edit jobs to exclude new vms, and we have a small number of jobs to deal with.  The limits per host and datastore ensure that we are running multiple vm backup tasks at any given time.

image  This is the key differentiator from VEEAM.  VEEAM only processes vm backup tasks one at a time.  So if I have 30 vms to be backed up in a job, it will plod through them one at a time.  If it hits a particularly large backup, you are stuck waiting.  On the flip side, with vRanger we can often have 6-8 vm backup tasks all running at the same time.  Sure, it will still take some time to backup the larger vms, but it is working on several others at the same time.  I talked with VEEAM at VMWorld about this a couple of weeks ago, and their answer was to setup additional backup servers to run things simultaneously.  Wrong answer.  Who wants to add another box you have to manage and try to schedule all that out?  No thanks.  The other option presented was to make a job for each vm.  HA!  Don’t even get me started on why that is a nightmare.

 

image

VEEAM is our choice for the smaller branch sites.  These have a small number of vms (about 10).  They all have CBT enabled.  These 2 factors mitigate the sequential nature of VEEAM, as the backups all finish in the nightly backup window just fine.  The killer features that made us use VEEAM for the branches is the Enterprise Manager and the Virtual appliance mode.  Enterprise Manager lets us see all of our backups and history for multiple installs of VEEAM across our branches from a single web page.  Very nice.  Virtual appliance mode will hot-add the vm disks to the VEEAM virtual server installed at each branch for backup, making them faster.  This is much easier to do than trying to “mount” the vmdk’s on a physical box like VCB used to be.

 

What are your thoughts?  How are you backing up your vm infrastructure both big and small?

Advertisements




Off-Site Backup Musings

23 04 2009

This is an exerpt from an email I sent to one of my colleagues. All these questions were off the top of my head, but hopefully will help someone in the process of backup strategy…Thoughts?

There are many things to consider with offsite backup of virtual OR physical machines. Some things to think about…

1. What are your most important applications? How long can these be down, worst case scenario?

2. What kind of restores do you TYPICALLY have to perform? Is your current onsite backup strategy fulfilling at least 95% of your restore needs?

3. Based on the answers to the 2 above, what solutions are available to cover you for that 5%, worst case scenario type of restore?

4. If you are considering ANY kind of warm or hot offsite solution, such as vm snapshots, ready to be mounted and ran, is that critical application data (email, databases, web services, etc.) up to the minute?

5. If the data is not up to the minute, how will you get it up to the minute?

6. If the data IS up to the minute, how will you FAIL BACK, when the primary site comes back online? How will those changes be replicated and added to the primary site?

7. How much is all this going to cost? Do a bang for the buck analysis based on restore time. For example, how much money will it cost me to get email back up and running in 4 hours as opposed to 8 hours. Or 10 minutes as opposed to 1 hour…..

8. How much bandwidth (upstream primarily) do I have to be able to send data to an outside party?

9. How do I get the data once its offsite, do I have to download it? Can I just go pull the device out of the rack and get my data?

10. If the power is out, what are people doing anyway? J

A lot of this really boils down how deep you want to go down the rabbit hole, but hopefully this will get you started. Before looking at solutions, you (and us too) need to figure out what’s acceptable down time, and build a strategy from there.





Veeam Offering 50% off upgrade till June

15 04 2009

http://www.veeam.com/go/backup-upgrade/

Not bad. This is one of the few products that is really supposed to work with ESXi. We are currently using Vranger from vizioncore, but it leaves much to be desired in the scheduling and historic detail category. There is supposed to be a new version of vranger coming out, but the details are few and far between on their site….