geographically separated B&R server

[ejenner]

Hi everybody.

Something I've wondered from time to time was how much of an impact having a geographically separate B&R server causes on RTO?

My target and source are 100 miles away from the B&R server and the link between the different sites is reasonable but nowhere near as strong as it would be if all components were on the same local network.

When I restore something you see messages talking about mount servers and that sort of thing. Could it be the case that the B&R server is using network bandwidth (WAN) to mount a backup which is sitting in a repository on the remote site and could this slow down the entire restore process?

What caused me to think about this was having two powerful systems which are only a few meters apart (in different rooms) on the same floor seem to restore from one to the other very slowly despite being on the same high speed internal network.

I had been of the view that the B&R server merely orchestrates file transfers but does not actually form a part of the chain once data starts to transfer for a backup or a restore.

Is there some fundamental flaw in this scenario with it being an atypical setup which would certainly cause slow restore times?

[HannesK]

Hello,
in general it's fine to have one central VBR server and proxies / repositories thousands of kilometers away connected via WAN links.

When it comes to performance issues during restore, there are several topics to keep in mind.
1) what kind of repository are you using (my question is about the gateway server placement if it exists)
2) where is the mount server located?
3) what kind of restore did you do? file level, application or disk / VM?
4) If file level, did you restore to the same location or different location?

Best regards,
Hannes

[ejenner]

In this specific scenario the answers are:

1) Windows Server 2019 on HPE DL380 with direct attached storage
2) accepted the defaults during installations
3) guest file restore
4) to an alternate location

[foggy]

By default, the backup repository server is the mount server as well (you can make sure this is the case in the repository settings) and the backup server shouldn't be involved in the process. Otherwise, the backup could be mounted to the backup server during the restore.

[HannesK]

4) file level restore to same location would be fast then. for alternate location restore in a branch office, the workaround is to install a console in the branch office (for alternate location, traffic goes through the console)

[ejenner]

It goes through the B&R server if restoring to an alternate location?

[PetrM]

Hello,

As mentioned on this page of our help center:

When you restore files or folders, the machine where the mount point is created connects to the VM over network or VIX API/vSphere Web Services

The mount point is created on the mount server linked to the repository on which backups are stored. Therefore, it will go through Veeam B&R server only if it plays a role of the mount server for repository.

The mount point will be created on the console if you instruct Veeam B&R explicitly to mount disks there using "Mount to console" button. For example, it might be helpful if you're going to leverage Microsoft Windows File explorer, more info can be found here.

UPDATE 29/11/2021: The statement above is not applicable for "Copy To" operation. Please see the post below for more information about "Copy To".

Thanks!

[HannesK]

It goes through the B&R server if restoring to an alternate location?

with "copy to" it goes though the console (from mount server to console to VM).

It's something we plan to improve, but for now it is as I described. The workaround from above is still valid.