Veeam Deployment Scenario

[sandeepchand]

Hello

I apologize if this topic has already been discussed in the past on this forum.

I am looking for guidance around the deployment of Veeam in a Prod & DR scenario.

The plan is to deploy infrastructure as follows:

Prod site
1 x vCenter Server
3 x ESXi hosts
1 x SAN (direct attached)
Physical server (Veeam proxy handling backup/backup copy jobs)
Tape library (directly attached to backup server)

DR site (100km from prod site)
2 x ESXi hosts (managed by Prod vCenter Server)
1 x SAN ( for replica VM storage)
Physical Veeam backup server with local storage for backup copy storage

Additional notes
The prod site will not have a Veeam B&R instance.
The prod site will also have a virtual proxy if its required for hotadd
10GB networking throughout (backups will take place over network)
The DR site Veeam B&R will run all backup and replication jobs. The fail-over plan will also be managed on the DR Veeam B&R instance.
The vCenter Server in the prod site will be replicated to the DR site.

In the event DR needs to be invoked, the replica Domain Controller and vCenter Server will be powered on by logging in directly to the DR ESXi host.

Questions
Is the above the best way to setup Veeam or would a second vCenter server be required at the DR site and 2 Veeam B&R instances (1 at each site with Veeam prod node running backup jobs and DR node running replication jobs)? I'm wary of the fact that there will be a conflict with daily backup jobs and hourly replication jobs if managed by different Veeam instances.

[foggy]

Hi Sandeep, your plan looks good. It is one of the possible deployment scenarios, but to me personally, the most effective one. Single Veeam B&R is enough and since you're using physical server as the proxy at source, you can consider utilizing direct SAN transport mode (though having a virtual proxy is also good).

[mtgj]

Hello,
We are looking at a modifying our current Veeam 9.5 deployment for a similar scenario, except that our "DR site" is MS Azure. Thus, our connection to it is much slower than in the original post here.

Our prod site has two ESX hosts, not 3, with one vCenter server and a direct-connected SAN. The existing Veeam Backup & Replication server is a physical server, with both internal and NAS-based repositories (not on the production SAN). We have a VM proxy server to assist with the backup of the on-site VM servers.

We have an existing VM in Azure that has our current offsite repository, with that Azure VM set as a proxy server.

The current, single, on-site, physical B&R server currently manages the backup copy jobs to the Azure repository.

For improved/simplified site DR, we are considering either moving the B&R server to the Azure VM or installing a second instance of B&R server there and having it run the backup copy jobs to it's repository.
According to this article, it seems like having the second B&R server may be the better bet, giving ease of restore for site failover, but maintaining local backup performance at the prod site:
https://www.veeam.com/blog/physical-vir ... ation.html

However, to do this, does it get into the potential mess with multiple B&R servers having access to the same repositories? Would the Azure-based server have to be connected to the prod site repositories to do the copy jobs, or does it just talk to the prod site B&R server?

Also, would Veeam Enterprise Manager have a useful role here, particularly with managing encryption of the jobs and potential recovery of the encrypted configuration etc?

[foggy]

However, to do this, does it get into the potential mess with multiple B&R servers having access to the same repositories?

In general no, provided both Veeam B&R instances are at the same patch level and you keep an eye on load, since each of them will know nothing about the second one (in terms of the tasks they assign to repositories). But in your case I would keep a single instance, since it is more convenient to have both regular backup jobs and backup copy jobs managed by a single Veeam B&R than setting up a second one to perform periodic rescans to import new restore points created by the first. It's a different story in case you do replication, which it is not tied up to backups and allows you to have a dedicated backup server in DR site just for that.