Link Search Menu Expand Document


A pool of workers is used by VBAZ to create backups of workloads, indexing Azure Files data and also for data processing operations, including creating archive backups and restore operations. You can change the worker size for different purposes, allowing you to choose a different worker size to backup small workloads vs larger workloads, or for data tiering operations.

In order for initial full backups to proceed quickly, it is a good idea to use a larger worker profile first and then switch to a smaller worker size for incremental backups. You can change worker profile settings on a regional basis, so make sure that the worker size is appropriate to process the largest workload within the required time.

Worker placement

Workers are deployed as an Ubuntu image and the binaries are downloaded from the provisioning Azure storage account. Workers are always placed in the same subscription and resource group as VBAZ. The region workers are deployed in depends on what would be most optimal placement from a cost and performance perspective:

  • Workers are placed in the region of the source workload when creating backups of Azure VMs, backups Azure SQL databases, and for file share indexing. File level recovery operations from snapshot are run in the same region as the source snapshot.

  • Workers are placed in the region of the target backup repository for archive backups of Azure VMs, archive backups of Azure SQL databases, as well as health checks, and retention processing. File level recovery operations from backup are run in the same region as the backup repository.

  • Workers are placed the region of the restored workload for Azure VM, SQL instance or virtual disk restore.

Learn more about Worker Instances in the VBAZ documentation.


Workers are given a network interface based on the worker pool settings configured in VBAZ. This network should be configured with an Azure Storage service endpoint. Workers need to be able to connect to the destination storage account endpoint.

VBAZ communicates with workers via the Azure Service Bus. Workers will need to have access to this service bus. When using private networking this will require a premium tier service bus.

For Azure SQL support, workers need to have connectivity to the Azure SQL DB or MI instance they are protecting. The endpoint must be accessible to connect to an instance outside of the subscription where VBAZ is deployed.

For Azure VM backup, no private link is required between the subscriptions. Workers securely backup source snapshots using a temporary SAS link. This allows for backup of workloads outside of the subscription where VBAZ is deployed.

Worker Sizes

Profile Machine type Purpose Backup Speed
Small F2s_v2 for backups of workloads with disks smaller than 100 GiB (default) 70-85 MiB/s
Medium F4s_v2 for disks between 100 GiB and 1 TiB (default) 90-100 MiB/s
Large F8s_v2 for disks over 1 TiB in size, also recommended for initial full backup (default) 125-140 MiB/s
Archiving E2_v5 to handle data tiering (default) 85-110 MiB/s

In order to check whether the machine size you select makes economic sense, you can visit

These maximums are based on testing and the recommended maximums for the specified config.

Type Value
Recommended workers for the default appliance size 50
Recommended workers for the medium appliance size 250
Recommended workers for the large appliance size 500
Maximum workers per region per appliance 1000
Workers per service bus (two queues per worker, based on default basic tier) 5000
Azure ARM API reads (per tenant/user/hour)* 12000
Azure ARM API writes (per tenant/user/hour)* 1200

*Learn more about Azure Management API request limits and throttling.

Back to top

Copyright © 2022 Solutions Architects, Veeam Software.