What VBAZ Backup Job Throughput Should I Expect?

[ratkinsonuk]

Hi all.

Does anyone have any real-world figures on what kind of throughput I should expect from Azure based VM's and infrastructure backups. If I flick through the current VBAZ backups, I see an average of around 100MB/s. There are only a handful of policies (newish installation) and are mixed, from a single VM to multiple large VM's, but they're all running at about the same rate.

I'm comparing this to our on-prem VMWare B&R instance, which typically runs at over 1GB/s. For info, I'm seeing throttling alerts in the console, but as not all backups run together, I would hope some of them are able to run at max speed.

Thanks, Rob.

[nielsengelen]

Hi Rob,

Within Azure, it is of course very different from compared to on-prem. Speeds may vary depending on the sizes of the virtual machines and connectivity impact. What you could do is open a support case to see if anything could be done from a worker perspective to improve it.

[ratkinsonuk]

Thanks Niels. We're still investigating internally, but I'll take your advice onboard if we can't spot anything obvious ourselves. I thinj the most likely test we'll perform is to seperate out the repositories into individual storage accounts to prove that's not the issue.

[nielsengelen]

Hi Rob,

There are indeed limitations to storage accounts, we also have a section in our user guide for best practices.

[ratkinsonuk]

Looking at this page - https://helpcenter.veeam.com/docs/vbazu ... ml?ver=8.1

It says "For example, one backup policy can only write to one storage account. When using a F2s_v2 worker size with 80 MBps throughput to a storage account that can handle 25 Gbps, you can have a maximum of 3 GBps of throughput to the storage account, so a maximum of 38 worker instances. This means that for a policy that protects approximately 50 workloads, the recommended maximum number of worker instances processing simultaneously is 38"

We've configured VBAZ for a maximum of 5 workers, but I think it's basically just using one all of the time. Do you think that's where the performance is coming from, that the maximum throughput from a single worker is 80MB/s?

[nielsengelen]

If you have 5 workers and are processing multiple workloads at the same time, you should see 5 workers. Are they all writing to the same storage account? This may explain the maximum speed being reached for the storage account.

[ratkinsonuk]

We have 2 storage accounts, one for Prod and one for Non-Prod. The repositories are then a folder within the account.

Rob.

[nielsengelen]

Hi Robert,

I would suggest contacting support for better insight then as you should see multiple workers be able to run at the same time. It could be related due to schedules of the policies or something and it's a big guess via the forums. Could you let us know the case ID once opened for future reference?

[ratkinsonuk]

Hi Niels. My apolgies, I gave you bad information. I've just started 6 backups, 3 for Prod and 3 for non-Prod. The maximum (5) workers were dynamically created. That means it's unlikely that the workers are the bottleneck, and points even more to the use of a limited number of storage accounts. Would you agree?

Thanks, Rob.

[nielsengelen]

Hi Rob,

Most likely you have indeed hit the limitation of the storage account then. You may be able to get changes done from Microsoft's side to get more throughput or another solution would be to use an additional storage account and see if you can get more performance.

[ratkinsonuk]

I think we need to at least try that 2nd option to see if it makes any difference. At the moment, there's only a handful of repositories to recreate, so not a massive job. I'll post again when I know more. Thanks for the input in the meantime.

Rob.