Backup Army ? Huh you say? Well that is exactly what you can create with Veeam v6. Here is a great quote from one of the head cheese over at Veeam:
“v6 backup proxies are like an army of drones. Create more proxies than you will ever need by putting them on your existing Windows servers, and intelligent load-balancing will be spreading the task among them as needed. Most proxies will sit there idle for months (because backup repositories can only handle as many concurrent jobs as you define), but when some proxies go down – other proxies will awake and pick up the tasks from their fallen comrades.
v6 is almost like a living creature, as it is able to adapt to the environment. For example, it does not try to use “dead” or “tired” (already loaded) “body cells” (proxy servers). Moreover, it specifically looks for “body cells” which are best suited for the task (closest to data). It also adapts instantly to outside influence (workload changes) by automatically putting more of its “body cells” into work to handle the disturbance.”
In Veeam v5 as well as with most other backup applications if you have too much data for one server to backup you simply create a second backup server and manually load balance the jobs, but with Veeam v6 you have management processes and worker processes. This allows you to centrally control all the jobs from one location, while distributing the worker processes across whatever (and however many) resources you have (virtual or physical). This allows Veeam v6 to scale from a few VM’s to even the largest enterprise environment.
So how do you know when one server isn’t enough?
The easiest way to tell if one server is enough is to measure how long your backups take. If they take longer than your backup window, a.k.a. the amount of you can let them run in a 24 hour window, then you probably need another backup server. Because Veeam Backup Proxies can be virtual machines this means that you can leverage the horse power of your vSphere cluster to do your backups by adding several Windows virtual machines as Backup Proxies. There are however considerations to adding virtual machines as backup proxies.
If you are a 24×7 shop and your vSphere cluster is already heavily utilized then I would not recommend making your backup proxies virtual machines (or putting the proxy task on existing windows machines). This is for several reasons, but the bottom line is that you will consume a lot of CPU, Memory, and Network resources from your cluster. A better option in a 24×7 shop is to utilize several physical servers with links into your SAN fabric to do the processing. I prefer to see machines that are dedicated for the proxy task as well, and if you must make your proxies virtual machines and your a 24×7 shop, I would probably set their resource priority to something lower than your critical VM’s.
If however everyone leaves at 5pm, or at least most of the users, then there is no reason not to create a couple backup proxy VM’s and put them on your production VMware servers.
So what does v6 “look” like?
So in Veeam v5 a basic backup structure looked similar to the following picture, you had your VMware ESX/ESXi servers, storage, maybe a NAS or dedicated server for Veeam backup storage, and one or two servers (or virtual machines) actually doing the backups. And the only thing that would hook multiple Veeam V5 servers together was the Enterprise Manager. Which really didnt hook them together at all… it just gave you a central interface to control jobs from.
In Veeam v6 a lot of things have changed. We still have our VMware servers, our storage, and our NAS or local storage for Veeam. But now we call this backup storage a “Backup Repository”, and instead of having one or more standalone Veeam servers we have a single Veeam server acting as a master, and several other VM’s or physical servers acting as “Backup Proxies”. This allows for a much more distributed architecture then the previous versions, which in turn allows the product to scale much larger.
Stay tuned for a “Backup Design” Article where I’m going to show you several ways to use V6 to design your new backup and disaster recovery infrastructure.
Thanks for the post Justin. We all look forward to your next post!
Good overview of the new architecture. Thanks.
I’m looking forward to you design article.
Thaks, looking for the design article as I’m deploying veeam 6 now.
A Q which isnt quite clear from the above suggestion of implementing proxies on existing Windows production servers after hours.
I’m guessing if you have say 4 servers, and server 2 and 3 are moonlighting as backup proxies, then it would make sense to not backup a proxy server while its being used as the proxy or does this make little difference? i.e. is it an issue, not a problem at all or is it a situation that is best avoided but no real crisis if its not?
e.g. in the above example would one ideally create 2 backup jobs
1. to backup VMs 1 and 2 using VM 3 as the preferred proxy
2. to backup VMs 3 and 4 using VM 2 as the preferred proxy