Sean Wallbridge
If you have been following my blog over the last little while you will know that I have faced a few challenges with Veeam in terms of setting up remote jobs (backups across the WAN). Well, I think I finally have some good news.
I was originally trying to do full Veeam backups of ESXi VM’s across the WAN meaning I was trying to perform a “normal” Veeam backup across the WAN. I had managed to do this with a particular customer’s VM under Veeam 6.5 and I thought the same process would work for others but I kept hitting roadblocks. At first I thought it was something to do with changes in Veeam 7.0 but it turns out to that it was far more complicated than that. As I indicated in earlier posts, the customer that I was really having problems with had fairly large VM’s with a lot of changing daily data, at least in one VM. Trying to back them up in a “normal” fashion across the WAN usually failed miserably and yet things seem to work okay with the other customer. It turns out that, 1) I was labouring under a misconception about the best way to perform Veeam backups across the WAN and, 2) it was just sheer dumb luck that backups for the first customer (the one started under 6.5) actually worked!
Now that I have gone through many more hoops at both customers as well as sorted through issues with Veeam support it seems that I may have some answers.
First and foremost, if you want to perform Veeam backups across the WAN you should be using Backup Copy Jobs as an adjunct to your “on LAN” Veeam job and NOT try to target a direct job out over the WAN (unless, of course, you have massive big pipes). The reason for this is that the Backup Copy Job is actually a backup of an existing backup and not an actual backup of a running VM itself. What this does is backup the last completed backup of a VM and it runs between the Veeam server and the Veeam repositories and does not impact the running VM. The end result is a fully intact and verified copy (hence the Backup Copy moniker) of your backup in your remote repository. This is particularly nice as it puts no load on your production VM or the hypervisor host. This can be particularly important if you have a busy VM and it gets impacted when a snapshot is taken or removed during busy operational periods.
Secondly, if you are serious about all of this then you want to upgrade your Veeam license to Enterprise Plus so that you get the WAN accelerator feature. Backup Copy Jobs are currently the only jobs that actually use the WAN Accelerator and from what I’ve seen it can make a very large difference in the amount of data that is actually transferred across the WAN. I originally thought the WAN Accelerator worked with all types of Veeam jobs, including Replication, but that is incorrect. I have been told that Veeam is considering how the WAN Accelerator feature might be enabled for other jobs but, for now, only Backup Copy Jobs leverage the capability.
I have happily running Backup Copy Jobs, now, and the remaining hair on my head is safe from being torn out any further. My thanks to Michael Strine at Veeam Support for helping to get me pointed in the right direction and for patiently working through the whole process with me.
Good post and glad to hear all is well. Let us know if we can help.
Note: I work for Veeam.
Thanks, Rick. Your name is familiar, have we spoken in the past? Just so you know, Veeam support has been super helpful as I rolled through all of this. I hit a couple of interesting situations (not bugs but interesting events) that made suppport scrtach their heads. Michael and his team really helped me out. — Robert
Great blog regarding Veeam. I too have been wrestling with this concept. Due to the variable Backup Copy selection options (Job, Backup, VM), each Backup Copy run makes a synthetic Full from the selected options (using existing backups).
Can you give a real-world comparison of the improvements you got from the Wan Accelerator? We are contemplating upgrading, but would like some data first.
Thanks!
I can’t give direct real world figures, undortunately, as we didn’t do “before and after” tests. What I can tell you is that the customer’s using it definitely see a lot less data going out over the WAN over time. The caveat here is that you have to have lots of available space on the Veeam proxies on either side of the WAN connection for the WAN accelerator to use to build its cache. And the more your data changes on the backed up machine, the more data will go into the WAN accelerator cache. As best I can tell the data goes into the cache once on each side of the connection and then gets “tokenized”. From that point forward tokens get passed from end to end to represent cached data and then some magic happens at the remote end for the copied data. I have no reason to doubt Veeam’s claims regarding how much the data stream can be thinned by using the WAN accelerator. In other words, I believe the cost for the upgrade is more than justified. Hope this helps! Robert