Now that Veeam Backup and Replication 6 is out we can start talking about the best way to setup your Disaster Recovery site replication. Because of all of the new things included with Veeam 6 there are a couple ways we can do replication now so the idea behind this article is to show you the best way that I have found to do it with ESXi 5.0 and Veeam 6.
Let’s first rewind and take a look at the old way and the challenges associated with it so that we can better understand why we will be doing replication a specific way with V6.
So back in the day, you had two choices from VMware… ESXi and ESX, with its service console. So when you are using past version of Veeam you can replicate to either ESXi or ESX, and when you replicate to ESX you had the option to replicate using the service console, this made replications much quicker. I don’t know the in-depth details but I would assume that it is because all traffic would be forced through the network stack on ESXi (which has limited resources) and on ESX the traffic was pushed through the disk stack which is much more robust, not to mention that the service console has many more resources at its disposal. The bottom line was that if you were replicating to a DR site, and wanted to achieve speeds greater then 10-15Mbps you needed to use ESX and the service console method.
Obviously, if you were going to be replicating to ESX that means that your VM’s could be a maximum of Hardware Version 7… which in turn means you would not have been able to upgrade to vSphere 5 (or at least not be able to replicate those VM’s on hardware version 8). So in order to allow customers to upgrade to vSphere 5 and start using ESXi 5.0 hosts at DR sites while maintaining fast replication speeds Veeam utilized its new “Backup Proxy” technology in place of the ESX 4.x Service Console. (It should be noted that Veeam Backup Proxies can be used with older versions of vSphere and even VI 3.5 as well, I just mean that since there is no ESX 5.0 it allows you to move to ESXi 5 easier)
Fast Forward back to present time.
Now that we understand why the service console was important it’s easy to understand why Veeam needed that Windows Backup Proxy at the DR site. It allows them to send Veeam replication traffic from one Backup Proxy at your main site across the WAN to a backup proxy at your DR site… then the DR site backup proxy can push the data down to the SAN or local storage through an NBD transfer method without using the ESXi kernel.
How it looks
If you are planning your DR strategy with Veeam then the following picture should serve as a good reference. It really doesn’t matter if you have one host at the DR site, or if you have several ESXi servers with vCenter too. For simplicity, the picture below is just going to have one ESXi host.
(Click to enlarge)
So how do you make it happen?
I will assume that you already have Veeam Backup and Replication 6 setup and have at least one backup proxy at your main site. I will also assume that you have an ESXi 5.0 host setup at your DR site with at least one datastore to replicate data to. So let’s get started.
Step 1 is to create a Windows virtual machine at your DR site. This just needs to be a generic Windows install, nothing special, the only thing I did was turn off the firewall so that it was easier to install the Veeam Proxy Agent.
Step 2 is to install the Veeam Backup Agent on the new Windows virtual server. To do this login to your Veeam Backup server and bring up the console. Then click “Add Server” and select Windows Server. Enter the required information and click on through the wizard. After adding the server we then have to make it a proxy. This is done by clicking on the “Backup Proxies” section on the left, then on the right… right click and select “Add VMware Backup Proxy”. Select the newly added server from the top drop down menu, and then enter the remaining information that the wizard asks for. You should now have your DR backup proxy added.
Step 3. Now we need to add our ESXi (or vCenter) server from the DR site to Veeam. Click the “Add Server” button at the top again, and this time choose VMware vSphere. Just like before follow the wizard but enter the information for the ESXi Server at your DR site.
Step 4. Now we can create our replica job. To do this click “Replication” in the top. Follow the wizard and when asked what destination to use select your DR ESXi host and the appropriate datastore at the DR site. Then click next, on the Job Setting’s step is where we need to make some changes.
On this screen we are going to tell the job that it can only use backup proxies at the main site as a “source” proxy, and only backup proxies at our DR site as the “destination” proxy. This is what is going to get data over the WAN the fastest. In the screenshot below I have selected all of the proxies at my main site, which is why it says “Multiple proxy servers” and my DR proxy server is the 172.16.60.32. Now we can click next through the rest of the steps and then start our replication.
After finishing the rest of the wizard (typical stuff like windows credentials for VSS etc) you can start your first replica job.
If you have any questions let me know. I am starting to put together an article on how to take advantage of the other new replication features in v6 like the “Limited Bandwidth” setting, and the new options that allow you to have Veeam change your IP settings at the DR site. Stay tuned.
Nice Post…I hope you have a lot more outlining with some of the new features of v6! Keep it up
One thing I’m trying to figure out is how I can “sneakernet” the base image from the the source to the target as I can seed a full base across the line.
That is the topic of one of my posts ill be putting up next week. 🙂
Hi Chris, a rough outline of how I did this was setup a backup job on the source side (using an ext USB drive as a new repository), take the drive to the DR colo, add it there as a new repo and rescan (Veeam should now see the job), I then had to restore the VM to the DR SAN (trying to run a replica using the seed generated an error), then map the new replica job to the restored VM. hth
Pingback: Veeam 6 Replication: Just how much better then V5? | Justin's IT Blog
How often we can set for replication? is it possible for continously?
There is a continuous replication option. However because Veeam uses VMware snapshots for backup and replication (as do all other image level products) it is not a CDP solution… it is only a near CDP solution.
Basically the process is this:
Snapshot VM -> transfer data to replica location -> remove Snapshot – > take snapshot -> transfer to replica location -> remove snapshot
over and over again…. so your RPO is as long as it takes for you to move the change data each time… it will vary.
I do not know too many customers that use this, because if something goes wrong with snapshoting you could have some major problems.
Great info on the subject… But something worries me when thinking about replication setup.
Do i need to place my veeam server on primary site, or backup site?
What happens if my primary site and my veeam server on it go down?
How do i perform failover in that case?
Should i replicate veeam server to DR site as well as virtual center server to ensure proper failover through veeam? I am aware that veeam 6 creates fully functional replicas that we can just turn on to get started.
When replicating virtual machines with Veeam to vSphere at your DR site, Veeam stores the files as “ready to go” VM’s. Meaning that they are no different then a VM you would create from scratch. And your restore points are stored as snapshots. So as long as you have a laptop or desktop at the DR site with vSphere Client on it you can power everything back on within minutes.
If your Veeam server goes down the only thing you lose is the ability to change the IP addresses and stuff like that automatically, which you could do manually on the VM’s.
I dont normally replicate my Veeam server only because Veeam is easily rebuilt. Veeam keeps metadata files that will allow you to install a new copy of Veeam and still access backup data (if you still have it), or to replicate your DR VM’s back to the Main site once its rebuilt.
Let me know if you have any more questions.
Is there any problem with having the Veeam server at the DR site and installing a backup proxy at the production site?
So if the production site was blown up, you would still have the Veeam server online at the DR site?
Nope there is no problem with that. Just make sure that you create a backup repository on that side and that when you create your jobs you assign the correct backup proxies for the job. The Automatic setting might work, but i have found that if you have a lot of jobs running it will just pick the remote proxy to run a backup job…. obviously that makes that job run slow as hell. lol
although i should mention that if you are replicating your VM’s to a DR site on vSphere you DO NOT need the Veeam server to start those VM’s up.
Justin, good article. I was googling when I found it. I have a few questions.
You mention that the speed performance when going from esx to esxi might have been disk, you were not sure. I was wondering on the other hand if the performance penalty instead was compression could not occur on the esxi host, instead the compression had to occur on the backup server (whether physical or virtual). We used to use vizioncore vranger and when we changed from esx to esxi, we noticed the performance decrease and was told it was because compression could no longer occur on the esxi host without the normal linux console. ie- compression (cpu and memory) had to be offloaded to something else, namely the backup server.
Second, after virtual machines are replicated to the DR site as you describe, can you then backup the virtual machines with veeam? This would be perfect to keep the backups away from the production site and eliminate tapes. What do you think? Obviously we would need storage at the DR site to hold the backups.
In this case, would it be best to have a hardware backup server at the DR site to backup the replicated virtual machines?
After upgrading to version 6.0 of Veeam B&R I was digging around to find out how to set this replication up with some of my other sites. Your post has hit the nail on the head and helped me get this setup with ease.
Excellent post, many thanks
Thanks for reading Chris!
I did everthing as in this post. All installation went fine.
When it came to do replication test (1 VM set in rep job), replication failed. The only difference I can see is that I have ESXi 4.1 not 5, and DR site is just ESXi standalone, not vSphere.
Is there any logs I can check?
Is my setup incorrect?
Veeam produces Log files. Or you can just right click on the job and select “Realtime statistics” It will show you the status of the last (or in progress) run.
If you have the free version of veeam at your DR site Veeam will probably not be able to replicate to it. For testing purposes take the license from your vsphere license manager (the one for CPU’s, not vcenter) and licenses the host at the remote site. then rerun the job and see if it passes.
You mentioned “If you have the free version of veeam at your DR” – I thought the only thing at DR site you need is generic Windows where backup proxy will be installed?
Veeam itself is standard version with 48 sockets licence where 10 is used only (at non-DR site).
I am in contact with Veeam support and they cannot resolve it 🙁
Thanks for the article ! very well done !
I have one question for you. In case of disaster on the main site, you can simply restart VMs on the DR site. But how can you come back to the main site ? To you have to setup an other replication job going from DR to main site ?
you are correct. You simple setup replication in the reverse direction.
Remember though that because Veeam now can “digest” a VM that already exists at a remote location it will basically look at the VM…. map out all its bits, then compare that too the one at the source side… then it only replicates the changes to the destination.
I did the setup and it works very well !
Just have one more question for you, on the job replicating the VM back from the DR to the main site, are you using the “replica seeding” option to re-map the VM to the existing VM ? I tried both with and without the map option but I cannot see any difference in term of speed (I have a Gigabit connection between my 2 sites)?
Thanks again for your help !
If you have a gigabit connection you probably wont notice much of a difference depending on the size of the VM. IF however you have a 10 meg connection you probably would. It takes time to digest the destination VM so that it can tell where the differences are, which in the fast of a gigabit connection provide a minimal savings.
Thanks for the article, very informative.
I am just wondering how this would work if you happen to have both Vmware and Hyper-V at your primary site. My particular configuration uses veamm to backup locally to disk and i backup vsphere vm’s and hyper-v vm,s. Would I need to setup 2 backup proxies at the dr site, one for Vmware as you have outlined above and one for Hyper-v?
Will this information be updated?
veeam is really a great software..I recommend using the latest version with all the patches.
The patches contains important updates which may fix issues and bugs.