Veeam Replication Best Practice and Veeam location

[blackforce]

Hi, I am trying to get some clarity on the Veeam best practice with regards to Veeam replication. The location of the veeam server and also the replication metadata.

Basically we have a production site with a couple of VMware hosts and also have a DR site with a couple of VMware hosts. The 2 sites have a 100MB link between them.

Currently we have a Physical Veeam server installed at the DR site with a proxy installed at the production site, and also a proxy installed in the DR site.

We have replication jobs configured to use the Source proxy as the Source and then the destination proxy as the destination. The replication metadata is stored on the Veeam backup server in the default repository. c: drive which is in the DR site.

My questions are :

1) Where should the physical Veeam backup installation be situated? DR Site / Production? or does it not matter really if using proxys?
2) In the wizard it says the Replication Metadata should be stored in the Source Site. What is classified as the Source site? Should It stay with the Veeam install?

Thanks for any help in advance.

[Shestakov]

Hi,

In your case VBR server should be on DR site. It can be a virtual machine as well as a physical.
By default Veeam backup server fills three major roles: It functions as a management point (coordinates all jobs, controls their scheduling and performs other administrative activities), as the default backup proxy (for job processing and transferring backup traffic) and it is used as the default backup repository.

Since you have dedicated proxies, VBR server acts only as a management point and backup repository. As the best practice for replications, repository for replica metadata has to be deployed in a production(source) site, where you are replication from; VBR server has to be placed offsite to achieve a fast recovery in a case of disaster.
Having VBR in a DR site you can configure re-IP rules for Microsoft Windows-based VMs, perform automatic failover/failback to eliminate the need for manual replica reconfiguration and ensure minimum failover downtime.
Here on the forum was a post explaining it. Thanks.

[blackforce]

So in my case I should add a repository to the proxy server in the Production site and then store the replication metadata there?

[Shestakov]

Correct.
Are you going to use backups as well or replicas only?

[blackforce]

We are going to do backups as well as replicas. Does this change anything?

I've tested the replicas from backups in v8 as well but since the backups since on cheaper storage im finding the replica speed much slower.

[Shestakov]

We are going to do backups as well as replicas. Does this change anything?

Not revolutionary. I`m just trying to seize your strategy.
Do you leverage WAN acceleration capabilities? Starting from v8 is available both for replication and backup copy jobs.

[mtoms]

I'm hoping someone could clarify the best way to setup a replication job.

I have 2 veeam backup servers one in the production site and one in the DR site. I have 3 jobs setup on the production site for local backups forever incremental.

I would like to know the best way to implement a backup copy job to the DR site Backup server and then a replication job. Which backup servers should the jobs be setup on? Can I use the backup data from the copy job as the source for the replication jobs?

[Shestakov]

Hello Matt,

Which backup servers should the jobs be setup on?

Best practice for replication jobs is to have VBR server deployed offsite and a repository for replica metadata placed in a production site. Please read other posts of the topic for the reasons explanation.

Can I use the backup data from the copy job as the source for the replication jobs?

Yes, it`s one of the new features of Veaam B&R v8. Click "source" in Virtual Machine step of the Replication job wizard and choose "From backup files" radio-button.
This post can also be useful to read.

You can also use WAN acceleration for both backup copy and replication jobs. Thanks.

[foggy]

Matt, so to be clear, I would set up backup and backup copy jobs on the production server and replication job on the remote server. Please note that you would need to perform repository rescan prior each replication job run, as described in the thread Nikita is referring to above. Also, unless you need to have additional copy of your backups in remote site, you could run replication jobs right from the local backups on the production site, since replication now also supports WAN acceleration.

[timshipp]

Hi,

I know best practice is to have the repository for metadata to be closest to the source. However in my case I am looking to do replication only, and control all jobs, failover, testing, etc. from the DR target side. So is there any negative impact to doing it this way?

Thanks,
Tim

[PTide]

Hi,

Your topic has been merged with an existing one, please review. If any questions persist kindly let us know.

Thank you.

[foggy]

Even having Veeam B&R located in the DR site, you still can designate any repository on the source site as replica metadata storage (which is highly recommended). It can be the proxy server, for example, which you still would need to have on the source for optimal data retrieval.

[kmfyhr]

Hi all, I'm looking for some advice/constructive feedback on making some changes to my current Backup/DR strategy.

First here is my current layout:
11 ESXi 5.1 hosts, 1 vCenter 5.5 server, about 300 VMs, 2 physical Veeam 8 servers (one with management console, the other just a proxy) with backend SAN storage for repositories. Also 6 LTO 4 tape drives.
We backup pretty much everything every day, then write to tape every day, and send tapes offsite daily, with 7 days of Veeam retention on local SAN, and 2 weeks of Tape retention offsite.

Here is what we have added:
We have started to rent Hot-Site/Co-Location (whatever you want to call it) space. We have Placed two physical ESXi servers, & SAN Storage at that location.

Here is what I am doing/thinking of doing, and would like advice/pointers/etc.
Current Local set-up remains the same, but eventually we will eliminate tape. To replace tape, I will utilize SAN storage at Hot-Site and push Backup-Copies with increased retention. I have created a Virtual Proxy connected back to our local Veeam servers, and created Repositories specifically for Backup Copies, with a GFS retention scheme.

I am considering ALSO creating another Virtual Veeam server at the Hot-Site but loading the full management GUI (not just a proxy) So that I can restore from the Backup Copy Jobs if necessary, and ALSO create Replicas of Mission-Critical VMs so they can be powered on at a moment’s notice. My thinking is that if I "push" replicas to the Hot-Site from the local Veeam servers, which if a true disaster were to strike my proxy system at the site would not be able to orchestrate/control Replica Power-On. Is that correct?

Currently my Veeam implementation connects to my vCenter server (local) for backups, if that vCenter is down, how will that impact my ability to power on / restore VMs at the Hot-Site, and how do I get around any difficulties presented by this?

Assuming I do need a second full function Veeam server at the Hot-Site, how do I properly license it? I do own enough licenses to cover every ESXi server I own, however they are currently all in one combined license file on the Local Veeam server

Again any suggestions/support are welcomed! I don't want to get this wrong!

[Shestakov]

Hi Kenny,
Your idea and reasoning are totally sane.

My thinking is that if I "push" replicas to the Hot-Site from the local Veeam servers, which if a true disaster were to strike my proxy system at the site would not be able to orchestrate/control Replica Power-On. Is that correct?

It`s recommended to make the server in the DR site(Hot-Site) run replication jobs. Please read the discussion in the topic and ask additional questions if you have any.

Assuming I do need a second full function Veeam server at the Hot-Site, how do I properly license it? I do own enough licenses to cover every ESXi server I own, however they are currently all in one combined license file on the Local Veeam server

That`s described in our FAQ:

You can install any number of backup servers using the same license file, as long as the actual socket usage across all backup servers does not exceed the licensed amount. To ensure compliance, we recommend that you use Veeam Backup Enterprise Manager, which provides centralized license management. Enterprise Manager reports actual socket usage across all backup servers, and can be used to apply the new v8 license file to all connected backup servers.

Thanks!

[kmfyhr]

Should the Enterprise Manager server be located at the DR site? or my local site?

[Shestakov]

Wherever you want it to be. Here is the description.

[foggy]

Currently my Veeam implementation connects to my vCenter server (local) for backups, if that vCenter is down, how will that impact my ability to power on / restore VMs at the Hot-Site, and how do I get around any difficulties presented by this?

In case your replication jobs are targeted to the DR hosts via vCenter server, you will not be able to failover via Veeam B&R and will have to start replicas manually. So it is worth targeting them to the hosts directly in this case.

[rfn]

We have quite recently switched to Veeam Backup & Replication and one of the goals was to replicate our most important VM's to one of our secondary sites, so that we can start them up in case of an emergency in the primary datacenter. In our case it would be 10-20 VM's. We bought a new (VMware) hosts that is almost dedicated for this.

The backup part is up and running fine - beside some stability issues that might be related to ReFS - but we haven't setup the replication yet. Our environment isn't that large... 3 hosts in our primary datacenter, and 3 hosts spread on 3 offices. We have a dedicated VBR server at the datacenter and a repository server at another site. I've been wondering if we should use the dedicated VBR server at the primary datacenter for the replication, or if I should setup a new VBR server on the repository server on the other side, to handle just replication.

The goal is of course to be able to start up the replicated VM's in case of an disaster at the primary datacenter, and that would of course be problematic if the disaster also hits the primary VBR server. The risk of that happening is pretty low, so the question is if I loose any functionality by using another VBR server for replication? Would I complicate things unnecessarily?

What would you suggest?

[DGrinev]

Hi René,

I'd highly recommend you to install dedicated VBR instance on the remote site that will manage replication jobs. You will be able to run failover\failback operations right from its UI in case of losing production site.
Please review this existing topic for additional information.

Thanks!

[rfn]

OK... I will review this thread and setup a dedicated VBR instance on the remote site. Thanks!

[rfn]

OK... one more question... The host that will be used as a disaster recovery server, and host the replicated virtual machines, is also used for some productions VM's and is a member of the central vCenter.

If the primary datacenter is down, then we will also loose our vCenter, and then the VBR server handling replication will have no way of doing it's failover. I guess it's not a good idea to connect the replication VBR to the hosts directly (both production and DR) since that will cause a lot of things to happen without vCenter knowing it. That's not best practice, right?

Can you suggest a way to set this up so that it will work? I guess that I could get a vSphere Essentials license for the DR host so that it could get it's own vCenter, since it's just one standalone host that doesn't have to be able to vMotion to the primary datacenter. Is that a solution?

[DGrinev]

Hi René,

Remote hosts can be added in Veeam B&R Console as part of vCenter Server and at the same time you can add them directly for replication purposes.
You will be able to start failover even when the production site is down.
Please keep in mind if you are going to add existing host in a direct way it should have a different name, for example, you can use the IP address instead of the DNS name. Thanks!

[rfn]

OK... but when a replicated VM is registered on the DR host, then it should be done through vCenter, right? Otherwise these VM's will be kind of "rouge", or isn't that a problem at all?

If day to day replication is done by communicating with vCenter, and then someday vCenter is gone, will VBR still know that the replicated VM's on the DR host, registered by it's IP address, are the same as the ones it has replicated through vCenter, so the re-IP settings still work? Do I explain is this in an understandable way?

Would it be better if the DR host is a part of another vCenter, fx. obtained by a Essentials license? In that way the replicated VM's will not be a part of the production vCenter and the DR setup would not be relying on the production vCenter that would be lost in a disaster.

A third solution would be to restore the vCenter server on the secondary site and change it's IP address to an address in the IP range of the secondary site. The secondary site has DC's that are part of the same domain that is running on the primary site, so it would just be a matter of changing the static IP in the DNS and then vCenter would be "up" (since it's referred by it's DNS name).

I have focused a lot on a complete disaster, where the primary site is completely gone for an extended time. However it's important the the replication setup will also work in a situation where the primary site is not completely gone and where the production vCenter might still be available, but we for some reason would like to fail over to the secondary site for some VM's. In this scenario it's important that fail back will work, so the setup must not be a "hack".

I really appreciate the input!

[DGrinev]

Hi Rene,

This isn't a problem at all, as replicated VMs already have unique IDs.
Important to switch your services in case of disaster to another site and apply re-IP settings, since Veeam would know the IDs of original VMs, you will be able to initiate failback without a problem.
In any case, both ways would work: standalone host or separate vCenter server.

Thanks!

[rfn]

So I should add the DR host as a standalone host (even if it's already added as a member of vCenter), fx. with its IP address, and choose that as replication target. What will happen with the VM replicas in vCenter, when they're added to the host directly? I could of course test to see what happens, but it's always nice to know if it's bad practice to do it this way.

[Shestakov]

Hello René,
As Dmitry mentioned, there is not much of difference if you use standalone host or vCenter as DR, failover mechanism will work same way.
Thanks!

[rfn]

OK... I will test it out to see if it works the way I have understood it from this thread. Thanks!

[YouGotServered]

In regards to the metadata storage - if you store it on your production site (which I assume is for performance), what functionality do you lose if your production site goes down? Does Veeam store a copy of that metadata in the DR site, provided you have a VBR instance there as well? I thought you needed the metadata, so I'm a little confused as to how things would function if it was lost.

[rweis]

You can safely remove <lose> metadata, it will be rebuilt on the next job run (though this run will take a bit longer than usual). (credit to Foggy for this in another forum entry)

[YouGotServered]

Got it. Is there a link to Foggy's forum entry? I'd like to read through it!

I'm assuming it can only be rebuilt if the sql data is present, correct? If not, I guess my whole understanding of the relationship between metadata, the SQL DB, and how they work together is probably a bit messed up.