Workers are used by VBA to create backups of workloads, indexing EFS file systems data and also for data processing operations, including creating archive backups and FLR 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.
If you want initial full backups to proceed quickly it is a good idea to use a larger worker profile for this and then change this to a smaller worker size for incremental backup. 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.
The tables in this section use the number of objects and their variations as a metric for estimations.
Workers are deployed as an amzn-linux-v2 image and the binaries are downloaded from the connected S3 bucket.
Workers are placed depending on the operation to minimize latency and cost. In the case of backup, workers are deployed closer to the target repository. In case of restore, workers are deployed closer to the instance being restored. For file level restore from cloud-native snapshots the worker is also placed in the same region as the source snapshot. Learn more about Worker Instances in the VBA documentation.
Workers are given a network interface based on the worker pool settings configured in VBA. This network should be configured with a VPC. Workers need to be able to connect to the destination account and instances. If you do not configure these for an AWS Region, the default settings of the AWS Region to launch worker instances and to perform data protection and disaster recovery operations will be used.
If you want worker instances to operate in private environments, that is to use subnets with disabled auto-assignment of Public IPv4 addresses to launch worker instances in AWS Regions, configure specific endpoints for services used by the backup appliance to perform backup and restore operations. For more information, follow the details described for configuring endpoints in AWS in the VBA documentation.
Worker sizes are based upon the size of the largest EBS volume. Below is the default table of used sizes that can be altered within the worker configuration page.
|Small||c5.large||EBS volumes are less than 1024 GB (default)|
|Medium||c5.xlarge||EBS volumes are between 1024 GB and 1250 GB (default)|
|Large||c5.2xlarge||EBS volumes are more than 1250 GB (default)|
|Archiving||c5.2xlarge||EBS volumes are less than 6 TB|
|Archiving||c5.4xlarge||EBS volumes are more than 6 TB|
In order to change VBA configuration, you can edit
/etc/veeam/awsbackup/config.ini. Only edit this if you know what you’re doing or have been instructed to do so by support. You have to restart services for any changes to be applied.
|Purpose||Section||Key = Value|
|Archive worker instances||[WorkerVmDeploymentOptions]||ArchiveWorkerMaxInstances=2 (default)|
|Worker disk size||[WorkerVmDeploymentOptions]||DataDiskSizeinGb=32 (default)|
Workers are deployed based upon the available vCPU resources per region. These are shared with production instances but can be increased via an AWS support request in case this would be required. For more information, see the AWS documentation.