DR Site / Same Subnet

[bryanmeche]

I'm new to Veeam and DR, so I'd like to know the best way to setup the following:

-We currently only have a single production site (vsphere).
-We will be buying a few servers plus a shared storage solution and placing them in a colocated data center for DR.
-We will place a Veeam server with a lot of storage both locally and at the DR site. The Veeam server will backup local, and push a copy of all backups to the DR site. We'll also use Amazon storage appliance so a third copy of our backup data is stored offsite.
-In a disaster we do not need replication so we will remote into the DR veeam server and begin restoring VMs. We also plan on doing this just to do for lab scenarios in our DR site.
-To fail back we'll take a backup of the server at the DR site and restore it back in live.

Now what I'm trying to figure out is how do I get my production Veeam server to talk with the DR Veeam server when a requirement is both Prod and DR need to be on the same subnet. Re-ip isn't an option in our case as we have a lot of applications setup where that wouldn't be friendly at all.

My thought is to have the Veeam server run two NICs on two different subnets but I'm curious to know how other people set this up with similar requirements. I figure NAT rules on the remote firewall is an option as well. We'll hopefully be up in a lab soon to test but I want to make sure I'm not making this over complicated.

[emachabert]

Perhaps i don't get the point here.
You want your DR site to be in the same IP subnet of your production site because you don't want any reip job to be done when failing over the Dr site ? Is that right ?
Both Veeam server won't have to speak each other, you'll simply have remote proxyies and repositories. In case of a disaster, remote Veeam server will import the replicated backups (which are on a remote repository managed by the production veeam server) and then restore them.

I think that one information we don't have is what kind of connection will be setup between the two sites, for the communication between production Veeam server and its remote repository.

If you are using a L2 link, then I don't see the problem since the subnet will be streched between both sites.If using a L3 link, then multiples solutions exist. You could be using some L2 over L3 tuneling, and then resulting in a streched L2 or using a dual homed Veeam server at DR site and using simple routing.

Perhaps I didn't get anything at what you were saying

[Lex]

What i did was using the local hosts file on various machines.

On producting site:
10.10.10.10 proxy1.veeam.local
10.10.10.40 vcenter1.veeam.local
5.100.10.11 proxy2.veeam.local (which is the public nat address on the dr site)
5.100.10.41 vcenter2.veeam.local (which is the public nat address on the dr site)

On the dr site:
5.100.10.10 proxy1.veeam.local (which is the public nat address on the pd site)
5.100.10.40 vcenter1.veeam.local (which is the public nat address on the pd site)
10.10.10.11 proxy2.veeam.local
10.10.10.41 vcenter2.veeam.local

That way veeam can access everything without knowing that NAT's do exist nor that machines are in the same subnet and replication or copy job does exactly what we want.