Offsite B&R Server

[Sim113]

Hi All,

Looking at using Veeam but we would be grateful if someone with far better understanding could advise if we are on the right track or not!

Office A and Office B, connected by 200Mb leaseline via VPN. ESXi host in Office A, nothing in Office B.

Idea was to host the B&R Server in Office B and Backup Office A ESXi Host using the Guest Interaction Proxy (assuming the backup goes straight to the B&R server in Office B?), so if there is a complete Office A outage, Office B still has the running B&R Server to control Restores / Replication failover and all the backup data etc

All good at this point until we decide it would be nice to have local Backup and Replication in Office A onto an older spare server, to allow for fast restores / failover in the event the Production ESXi host died.

Now we are confused.... Can we have the B&R server based in Office B, but also have a 'local' backup and 'local' replication onto the old spare server in Office A aswell as DR backup and Replicas onto the B&R server in Office B?

Do we need to setup multiple jobs? i.e Local backup / replication job and Remote backup / replication job to the respective repository? Not sure this seems a great idea as there will be lots different backups and replicas around?

Would a Backup copy job to Office B be the solution? Can you use this for replication aswell?

Hopefully someone can make sense of what I've written vs what we are trying to achieve!!

Thanks.

[Mike Resseler]

Hi Simon,

As always, there are a lot of potential options. Let me look at what I would consider...

Installing Veeam B&R in office B is indeed an option. However, that means all data will go automatically from A to B. What I would do in this case would be: Backup data on a repository in A, and then do a backup copy job (maybe even with Wan accelerators) to B and you are compliant with the 3-2-1 rule.

Another possibility. Have the B&R server in A, do backups to a repository on A and then do a Backup Copy Job (again, consider wan acceleration) to a repository to B. In worst case scenario you can simply install a new B&R server in B and import the repository and you are good to do restores again.

Both scenario's have the advantage that the short-term recovery is done in A, which means fast recovery versus doing a recovery over the WAN which could have blockers at many levels, beyond what Veeam can control.

RE replication: Why not do backups locally and replicate from that backup to B?

I can actually give you a few more options here, but my advice would be to contact your Veeam representative and let one of our local engineers have a quick chat with you and give you the best advice on a solution

Hope it helps
Mike

[Sim113]

Hi Mike,

Many thanks for your reply.

The initial idea with having the Veeam server in Office B, was purely on the basis that if something serious happened in A, we would hopefully have one less thing to worry about rebuilding!

Having only used Veeam 7 and 8, the Guest Interaction Proxy is new to us, but from your reply, it appears it can quite happily be run from the B&R server in Office B, but still point the actual backup to a repository located on the old 'spare' server in Office A? Or have I misread that?!

If that is the case, I think the backup copy job to Office B would cover the offsite side of things off fully.

RE replication: Why not do backups locally and replicate from that backup to B? - Just to clarify, do you mean run the backup copy job to Office B, then use the Replica seeding feature to create the replica from the backup copied up using the backup copy job?

In addition to the backups, is there a way of having the VM's replicating to the old server in Office A and also have this copied/replicated out to office B along with the backups via the backup copy job.

Thanks again

Simon

[Mike Resseler]

Hi Simon,

All correct. I believe it was in version 9 that we made a lot of enhancements so that these (what we call) Robo scenario's work and the data doesn't have to be sent over the wire all the time. So have your B&R server in Office B, have one server in office A that is used as a repository server (that will run the components such as the proxy and mount server etc...) and you are good to go.

And then indeed you have options... I proposed a backup copy job from A to B to have it offsite. But you might also want to consider (as you kind of say yourself) to replicate from the backups on the repository of office A to office B (means no more touching the production environment resources). So take the replica from the primary backup, not from the backup copy job (although that is possible also)

And for your last question... Yes, giving you even more options. Replicate the servers to that old server in office A giving you a quick solution in case a single server dies (or a few). Then have a backup locally also, and then do a backup copy job to offsite.

Lot's of possibilities

[skrause]

The setup described is effectively what we have setup (though we have 3 datacenters instead of 2).

All of our backup jobs are managed from a B&R server in the non-production datacenter which has repositories, proxies, etc in the production datacenters so the jobs are backed up in their "local" location. We then run backup copy jobs to send the backups to the datacenter where the B&R server is located for 3-2-1 rule stuff (longer term disk retention and tape).

For replication, we do things just a bit differently but it basically comes down to us having the B&R server that manages the replication jobs in the target datacenter so that in the event we need to fail over, there is no additional setup time needed. We just run our failover plan in Veeam along with the manual things our applications require be done that cannot be scripted.

It works pretty well.

[Mike Resseler]

Steve,

Thanks for the additional information! I am sure this is helpful for Simon! Thanks!

[Sim113]

Mike, Steve,

Many thanks for your time on the replies, much appreciated. Useful info Steve in that you're already doing something very similar to what we are looking to do.