The common requirement for offsite replication is that one Veeam transport service runs in the production site (closer to the source host), and another transport service runs in the remote DR site (closer to the target host). During backup, the transport services maintain a stable connection, which allows for uninterrupted operation over WAN or slow links.
Thus, to replicate across remote sites, you should deploy at least one local backup proxy in each site:
1.A source backup proxy in the production site
2.A target backup proxy in the remote DR site.
The backup repository should be deployed in the production site, closer to the source backup proxy.
When planning for off-site replication, consider advanced possibilities to reduce the amount of replication traffic and streamline replica configuration — replica seeding, replica mapping, network mapping and re-IP.
In this scenario, the following connections need to be open between the Veeam Backup & Replication components:
•Veeam Backup server should have access to vCenter server, ESX(i) hosts, and both source and target backup proxies.
•Source backup proxy should have access to the Veeam Backup server, source host, target proxy, and source vCenter server.
•Target proxy should have access to the Veeam Backup server, source proxy, target host, and target vCenter server.
If you are planning for offsite replication over WAN, it is strongly recommended that you deploy a proxy server on the target side.
With a proxy server set up on the target side, the data will cross the WAN compressed and will be uncompressed by the target proxy. Note that you also can seed the replica job by sending your backup files offsite (using some external media, for example) and then have only incremental job runs.
It is also recommended that you install an additional Veeam Backup & Replication server in DR site; there shouldn’t be any issues related to the license, since Veeam is licensed by physical CPU socket of source hypervisor host (where protected virtual machines reside), not by Veeam server. In this scenario:
•Veeam Backup server deployed in the production site will be responsible for backup jobs and/or local replication
•Veeam Backup server in the DR site will control the remote replication jobs.
Thus, in disaster situation all functionality (Failover, Failback and other) can be performed by Veeam Backup & Replication Server in DR site without any problems. Additionally, it may be worth installing Enterprise Manager to have visibility across two backup servers, and in case of failover you can manually revoke licenses from the host that is down.
•Replication bandwidth estimation has always been a challenge, depending on multiple factors such as number and size of VMs, change rate (at least daily, per RPO cycle is ideal), RPO target, replication window. Full information about these factors, however, is rarely at hand. As an option, you may want to setup backup jobs that mirror what you would do with a replication job, and use the "transferred size" to calculate bandwidth (as this would be the same amount of data used for replication).
•Also, when replicating VMs to a remote DR site (or performing offsite backup), you can manage network traffic by applying traffic throttling rules or limiting the number of data transfer connections. See Veeam Backup & Replication User Guide for more information.