Backup O365 Repository Virtual Machine- Best Practises

[TSb4ckup]

Hi everyone,

so I have used VBR for a few years now and setup some veeam O365 backups on the smaller scale. Usually those O365 instances were backed up either to S3 or Wasabi.
With this new infastructure I am managing now there needs to be an onsite backup of O365 data as well. On the VBR side we are running tape and hardend repository.

Currently the Veeam for O365 server is a VM that has a seperate disk for the O365 repository which is then backed up by VBR to the hardened repository. Currently O365 data is about 6TB backed up and I have noticed a massive performance hit regarding this disk. While our onsite Exchange has about 5.5TB and takes about 15mins for an incremental backup the 6TB O365 repository takes more than 12 hours.

Application awareness is enabled and working, so is CBT. However it seems like VBR is attempting a full backup on every run with the O365 repository.

Are there any best practises or advises for this kind of procedure you can share? I'd be very grateful for any input on how to handle this kind of infrastructure.


Best regards.

[Moderator: Edited Topic Title to reflect scenario]

[david.domask]

Hi Tim, welcome to the forums.

Just for clarification purposes, want to confirm that the main focus of your question is related to the backup of the Veeam Backup for Microsoft 365 (VB365) repository VM with a VM backup or if it's about the performance of the VB365 operations; mostly just a housekeeping thing as if it's about the VM backup, will move your topic to the correct forum and answer further there.

What is listed as the bottleneck for the job when it's taking longer than expected? And if it's a VM backup, can you confirm for us and tell which transport mode is used?

[TSb4ckup]

Hi David,

on second thought the topic is probably better off in a different forum, as its not really regarding the O365 backup itself. Sorry for the inconvenience.

As for the bottleneck, it is currently listed as Source with 99%. Read speed on the SAN is not fully utilized at all though, proxy isn't really occupied either. Transport mode should be hotadd via the virtualization appliance. Is there any way to check to be sure?


Thank you very much in advance.

[david.domask]

Hi @TSb4ckup ,

Thanks for the clarification; we did move the topic and I DM'd you just in case you miss this.

Checking the bottleneck from the HTML report (right click the job, select Report) or from the Job Statistics window should be plenty, and you can confirm the transport mode used from the Job Statistics window as well (select the VM in question from the left-hand list of virtual machines, the view will change to show the machine task session information)

You mentioned it should be hotadd; did you set this manually on the proxy or it's on Auto-Select?

If you could confirm the above, we can advise better on next steps.

[TSb4ckup]

Hi David,

judging from the job statistics the server ist backed up by the network block device protocol (so no hotadd?). Bottlenecks are Source with 99% and Proxy with 17%.

On the proxy transport mode is set to automatic selection.

[david.domask]

Aha, so sounds like it's using NBD and Direct SAN and Hotadd were not possible for this VM.

If possible, give a read through our requirements for hotadd here: https://helpcenter.veeam.com/docs/backu ... iance-mode

I'm guessing you don't have Direct SAN/NFS configured else it would attempt to use that, and it's a fairly intentional configuration so I think for the moment let's assume that hotadd is the best transport mode that is possible.

Try working through the User Guide article and if you have different proxies available to test with, try forcing another proxy. If you are still having challenges getting hotadd to work, let's have you open a Support Case and include logs from the affected job. (Select the 1st radio option, and select the job which backs up that virtual machine)

Keep in mind that like all transport modes, the performance of hotadd will depend on many environmental factors; I do expect you will see some performance increase, but depending on various factors the speed may vary.

Please share the case number here if/when you open a case.

[TSb4ckup]

Hi David,

I think I found the issue. I tried reconfiguring the backup job by manually assigning the backup proxy and setting the transport mode on it to "Virtual Appliance (hotadd)". When starting the backup run it started to use NBD again and produces the following log entry:

Code: Select all

[ProxyDetector] Detected proxy VM (or another VM with same bios UUID) in task list, cannot use hotadd mode

We are actually using the VO365 server as a proxy for the main backup job and that is probably why hotadd isn't possible on this single VM only. Could I circumvent this problem by preparing a separate backup job for this VM and assigning it a different proxy?

[david.domask]

Hi Tim,

That could do it, but to be clear, it's acting as a VMware proxy in the environment in addition to being the VB365 server? The duplicate BIOS uuid message makes me more think that either:

1. The proxy VM is being replicated and the replica is causing the duplicate BIOS UUID -- you should be able to adjust this in VMware but I think it requires down-time for the VM for a reboot.
2. The proxy is indeed being backed up by the job like you're thinking; I think this is most probable given your description and the warning from the logs.

Try with another job + proxy, and I think you should see that hotadd takes and likely you will see better performance.

As you mentioned that you also had concerns about CBT not being used, likely it's caused by the same configuration issue as noted here:

If you back up proxies that use the Virtual appliance (HotAdd) mode to process VM data, the change block tracking mechanism (CBT) will be disabled. For more information on CBT, see Changed Block Tracking.