Question about failover with replication

[davidb1234]

Looking over the documentation it appears that the Veeam B&R server needs to be located at the DR hot site to do any kind of failover in a DR situation.

Say I have an entire office being replicated to a DR hot site. I have a B&R server in the main office that handles nightly backups and also replication to the DR hot site. Say this main office gets hit by a plane. It appears that I would not be able to fail over to my dr hotsite where the replicas reside because I lost my B&R server in the main office. It specifically says don't just power on the replicas without using the Veeam console.

Can you install multiple B&R consoles and have them be aware of each other? How does one go about setting this up so that this scenario doesn't exist and you can properly fail over in a full on DR situation?

Also I was curious how the replication metadata is impacted as well. If you have the replication metadata saved to a store that is at the main office site and that site get hit by a plane and is gone along with your B&R console that seems like not a good scenario.

Should another veeam B&R installation be performed at the DR hotsite to save all of the replication metadata and to create the actual replication jobs on?

[tsightler]

Actually, the B&R console is not "required" to failover especially in the case of a complete loss of the source site, but you do lose some things such as Re-IP and the ability to perform simple automated failback. Basically if you power on your target VMs without using Veeam, we are no longer able to track the state of this VM, that's the reason. In the disaster scenario you describe, that's not really a big deal since your remote site will be gone.

The replication metadata is not used for failover and is not "critical" in any way, it is only used for the actual replication (it contains the hashes used for source side dedupe). If it's missing it will be recreated on the next replication run, once again, not an issue for the scenario you describe. The metadata should always be located on the "source" side of the link as it's the source proxy that uses it during the replication process itself.

Ideally though, I always recommend that for replication that the B&R server be located in the DR site. When you perform a failover functions like Re-IP are performed by the B&R server itself, if this B&R server is on the source site all of these functions are performed across the replication link, which can be slow, and, as you have pointed out it's possible that the B&R server will be lost with the source site.

For simplicity a B&R server at the target site is ideal, you simple use a server at the source site as a proxy, and a repository for metadata, and that way you have the B&R server available for failover. Not only that, but in the event that a "plane crashes into your source site" you also have a B&R server ready and waiting to perform backups at the DR site after the failover (I'm assuming you'll want backups once you failover).

[davidb1234]

Thank you very much for the details. So to confirm I should do the following:

1. Keep the B&R installation at source site which handles all nightly backups to locally attached storage
2. install a new SQL instance at DR site + B&R and set up all of the replication jobs to run off that server. Keep the source site as the metadata repository.

So I can have 2 VEEAM installations one handling the backups and one handling the replications with the replication B&R instance running at DR site and the backup B&R instance running at main office site and both B&R installs will have completely seperate SQL databases.

Also will Veeam be able to failover to the replica VMs is the VCENTER server in the main site is offline?

[davidb1234]

Can someone answer if VCENTER is needed to failover to a replica at DR hot site? Assuming VCENTER is located at main office and main office was hit by plane and gone can Veeam B&R located at DR hot site still initiate a failover to a replica since the VCENTER server is no longer online(it was located in main office that is now gone).

[tsightler]

Customers generally take two approaches to this. Many customers run a second vCenter at the DR site, others replicate the vCenter or provide some other means for vCenter resiliency at the DR site. I personally prefer the idea of a second vCenter because that means you will also likely have a secondary DC/DNS server at the DR site online as well. I think this makes failover much simpler. Customers with a completely "cold" DR site have to manually failover infrastructure servers like DCs, vCenter before starting failover operations. If you have the core infrastructure already in place, this makes the process of failover much simpler.

[dellock6]

My 2 cents, there are some services that technically you do not failover to DR, but you rather build from the beginning to be distributed in both sites, first coming to my mind are Active Directory Controllers and DNS servers. It this way your infrastructure is completely redundant in both sites.
As a general rule, analyze first what kind of workload you are dealing with, and find out if it's best for it to do DR or BC (business continuity).

Luca.

[davidb1234]

Thanks again for the further comments. it appears that running a seperate vcenter in our dr environment to manage the DR ESXi servers is the answer.

Will I be able to failover to the DR site and do reIPing witha vcenter in the DR site but not contact to the vcenter for the source servers in the prod environment?

[foggy]

Yes, you will be able to failover.

[trialuservista]

I am new to veeam, i have a question, normally i use Veeam backup and Recovery in V center fail over to DR site. and i can pick which backup to fail over. WHat if my Vcenter totally down, can i still fail over from DR site, using Veeam proxy? If yes, what is the procedure?

[Vitaliy S.]

If your vCenter Server also manages the DR site, then Veeam backup will not be able to send API calls to power on replicated VMs, thus failover via Veeam backup console will not be possible. Please look through this thread for available options.

[getzjd]

We have 2 sites. 1 vCenter server at site 1. Production VM's in both sites. Veeam 6.5 patch 1 server at both sites. Replication configured for key VM's at each site to replicate to the other site. Failovers of standard VM's such as Exchange, file servers, etc work fine.

vCenter is configured for replication from site 1 to site 2. In the event that site 1 were to experience a disaster, what would be the proper procedure to bring up the vcenter replica in site 2 with a new IP? vCenter replication job is currently configured for re-ip, but without an active vcenter server, veeam would not be able to handle the failover to the vcenter replica correct?

Thanks!

[foggy]

Jay, your understanding is correct. In this case you need to manually failover vCenter server before failing over other VMs.

[jpipdw]

We're in the process of building a DR site at a remote physical site. We're currently backing up using Veeam to a fibre SAN, and we plan on using Veeam Replication to replicate the entire main site over to a remote DR site with similar hardware and networking.

I am trying to determine if this is possible. The scenario I was thinking was this:

1) Fire occurs, temperature rises, everything burns or powers off due to high temps
2) Veeam is running at both sites
3) Fail over with Veeam at remote site

My question is - if there happens to be a disaster at the main site, and lets just say the main site is too dangerous to enter and completely burns to the ground. Will we be able to stand up all of our VM's at the remote site? Is this possible by right clicking on a VM or datacenter using Veeam at the DR site, and failing them over? From what I've been reading, the only examples I've seen have been admins manually failing over from the main site.

What if the main site is completely unavailable? Will we be able to perform a failover and stand up VMs from the remote DR site? Assuming the vCenter server at the main site is also down due to the disaster.

Also, are there automatic failover options available with Veeam Backup & Replication?

I appreciate any feedback.

[kjc3303]

You will need to manually start up you vCenter server first then you can use the right-click fail-over facility within Veeam to fail over the rest of your VM's

Best practice (IMO and others on here) is to have your Veeam server at the DR site managing your replications so you do not need to restore your Veeam server first.

Also, are there automatic failover options available with Veeam Backup & Replication?

Not that I am aware of

Kev

Edit I assumed that your vCenter server was a VM and replicated? if not then you would need to have some other form of HA for your physical server eg vCenter Heartbeat

[jpipdw]

Thank you for your response!

Our vCenter server is currently a physical server at the main site. Our current Veeam B&R server is a VM in the cluster at the main site.

I fully understand the need and best practice to have an additional Veeam server at the DR site managing the replication - that is a great idea.

Not having auto-failover is definitely not a dealbreaker - just confirming that we will be able to perform various failover functions a the DR site.

Would you recommend running vCenter in linked mode if we have one physical vCenter at the main site, and a vCenter VM at the remote site?

Cheers

[jpipdw]

On a separate note - I have been researching building our own private cloud vs. taking advantage of replicating to a public cloud, making resources available at a remote cloud site.

[kjc3303]

No problem, here is a good post from Tom Sightler

Customers generally take two approaches to this. Many customers run a second vCenter at the DR site, others replicate the vCenter or provide some other means for vCenter resiliency at the DR site. I personally prefer the idea of a second vCenter because that means you will also likely have a secondary DC/DNS server at the DR site online as well. I think this makes failover much simpler. Customers with a completely "cold" DR site have to manually failover infrastructure servers like DCs, vCenter before starting failover operations. If you have the core infrastructure already in place, this makes the process of failover much simpler.

I 100% agree with his strategy although I do replicate my vCenter server at the moment and would manually start before failover.

[jpipdw]

Great information. Its good to have options. Just need to determine if running vCenter in linked mode would work for this purpose.

[kjc3303]

I am not sure it will to be honest I think you need vCenter heartbeat, I don't use either so could be wrong

you could have a separate vCenter to just manage you DR ESXi's - and have the in linked mode for visibility

[dellock6]

Guys, you can simply have two distinct and simple vCenter servers, and register both of them into Veeam. Replica tasks will move VMs from one datacenter to the other, there is no need to have linked-mode or heartbeat.

Luca.

[DavidReimers]

Hi all, I wanted to follow up with a couple of questions and clarifications.

I've deployed Veeam a few times, initially back in the day before failback from a replica (the process was manual). So my last deployment of 6.5 a few weeks ago used the same method (Veeam server at prod, replicating to standalone ESXi hosts). Having read this thread, I've moved by Veeam server to the DR site (which by design has no vCenter or DCs for simplicity / licensing etc) and put a proxy at the production site. Existing jobs are working fine. The prod and DR sites are connected by a 1Gbps link.

So I undertand the need to have a proxy on the prod ESX cluster. But why would I want to put the backup repository at the prod site (in earlier threads here, called the 'source site'). I've created a repository on the prod backup proxy, but I am concerned that in a DR scenario, we'd possibly lose some functionality?

We're using the replications for both backup (maintaining a month's worth of daily backups, which seems to be working OK so far) and for DR.

Could anyone clarify either the requirement or the desirability to have the backup repository at the source site? Especially when considering the prod-to-DR site link is 1Gbps. Would a 100Mbps link make a difference?

Cheers,
Dave.

[veremin]

Hi, David. You’re talking about place where replica metadata is stored, aren’t you?

Veeam Backup & Replication uses this replica metadata in order to determine what blocks have changed between two replica states. Thus, it’s always advisable to store this file as closer to the source host as possible, so that, VB&R will detect the changed block quickly, and won’t try to communicate with remote repository to get the required information, which is usually quite a time consuming process. So, this is just a matter of time/convenience.

Hope this helps.
Thanks.

[james575]

With the discussion here about having a second vCenter server at the DR site, is there any reason to have the second vCenter server if the DR site only has ONE ESX host? Would it be simpler to have Veeam just target the host directly for replication failover?

[dellock6]

Hi David,
from a design perspective, if you have no real speed difference between production and DR site, obviously some of the design best practices do not apply. But having the metadata repository near the source proxy is useful (as Vladimir explained) and also easy to do, since you already have a proxy in the production site, simply add a repository role to it.

Luca.

[veremin]

Would it be simpler to have Veeam just target the host directly for replication failover?

If your target host isn’t the part of vCenter server, you can easily add it to the backup console as a standalone host and stick with this scenario.

However, if you try to add an ESX(i) host that it’s managed by existing vCenter server (which has been already added to backup console), you might face certain kind of issues. Thus, it’s advisable to follow the aforesaid recommendations, at least, till the time v7 is released.

Thanks.

[mrstorey]

Does anybody know if this bug was fixed in v7? - 'failing vcenter vm replica over to standalone host that's registered within vcenter' ?

We have a DR test coming up soon (failing production servers + company vcenter over to secondary production site) and I'd like to utilise veeam replication if possible. I have a b&r server at the secondary site orchestrating jobs at the primary site, and I'd like to start configuring replication jobs from this server. Can I replicate and failover / failback my vcenter server to a standalone host registered with the veeam server at the secondary site, even if it exists in the vcenter database?

[veremin]

Just talked to QC team and they confirmed this bug had been fixed in version 7. So, replicating to standalone host that is also a part of vCenter shouldn’t be the case any longer. Thanks.

[jtupeck]

We are beginning our (more serious) DR initiative in my company. Our current setup is as follows:

vCenter at primary site - manages local datacenter and the remote datacenter
Veeam B&R at primary site for backups, SQL cluster database
Veeam B&R at secondary site for replication jobs, using it's own standalone database on the B&R server itself

Seeing as the vCenter server at the primary site handles the management of all our hosts, including those are the DR location, what would happen in the event that vCenter was unreachable and I wanted to turn on a Veeam replicated server? Would the B&R server at the secondary site be able to do this without vCenter access, or would I need vCenter in order for this to work? The reason I ask is because we are debating whether we need a dedicated vCenter for the secondary site, or if we can simply repliacate the vCenter appliance to the secondary site (using B&R) and spin it up first in the event of a DR scenario prior to doing anything else with the other replicas.

Throwing this out here, as I am sure we are not the only ones looking to see how best to accomplish this and hoping someone can chime in and fill in any holes in my understanding. Thanks!

[foggy]

Jason, you're right assuming that this question has already been discussed before. Actually, both approaches are viable and are successfully used by other users, so you can review the thread above and decide which one serves better for you. Thanks.

[jtupeck]

Perfect! I wasn't finding what I needed via search, so thanks for merging my thread.