Part 1 here: Veeam Replication – Installation
Part 2 here: Veeam Replication – Configuration
Now that we have Veeam installed, and configured with both site’s vCenter servers, lets get the replication job created. In the navigation tree on the left, select Backup and Replication, and choose to create a new replication job.
Give the backup job a name, and a description. To keep the lab simple, we will assume the virtual networks are the same name, and that the VM will not need to be given a new IP address at the secondary site.
On the next screen, click the Add button, and expand down the vCenter’s hiarchy to the virtual machine to be replicated, and choose to add it.
Now for the destination settings. Choose the secondary site’s vCenter server, a resource pool at the remote site, and the datastore to replicate the VM to.
After clicking next,the options for a repository for the replication metadata is presented. This data should be local to the protected site, in our case, the default Veeam backup repository. A default suffix to attach to the VM name is _replica, which will be used to distinguish the replicated VM’s in the seconadry site’s vCenter inventory. I left the default of 7 restore points.
Keep in mind the the restore points are just that, the number of replicated points in time to retain. If you replicate once a day, this would equal 7 days. If you replicate once an hour, then we would only be retaining 7 hours worth of restore points.
Next up is the data transfer options. For the lab, these will be all default. In a real world scenario, you would likely deploy proxy servers at both sites to distribute the load. If you are licensed, you can use the wan accelleration feature to keep a cache of blocks to greatly speed up all future replication instances.
Guest processing. If you are replicating Windows VMs, then most likely, you will want to enable application aware processing, to allow Veeam to instruct windows to do a VSS snapshot, enabling application consistancy Windows, inclusing Exchange and SQL. Be sure to enter credentials of an account that has proper access to that VM.
Finally, the scheduling options are presented. For the lab, I chose to replicate every 15 minutes, and left the default retry of 3 attempts. The retry is helpful, since other vSphere operations (backups, snapshots) may result in the first attampt to fail due to the other operation locking the VM.
A reminder that since this VM will be replicated every 15 mintues, and we kept the default of 7 restore points, we will have the ability to go back in time 1 hour, 45 minutes.
To wrap it up, the summary screen allows us to review all our selections, and submit the job to run imediatly if desired.
After a handful of minutes, the test virtual machine has sucessfully replicated to the remote site, and will continue to do so every 15 minutes.
Next up, we will cover the steps to failover to the secondary site.
