Veeam Backup for AWS: Workers

In the previous post we looked at Veeam Backup for AWS (VBA) appliance architecture and deployment. To protect AWS resources VBA uses two methods: worker based and AWS native protection (snapshots and backup vaults). We will treat native protection in future posts where we will look at the backup process for different types of resources.

Workers are part of the VBA architecture. They are temporary instances deployed automatically at the beginning of a backup, restore or retention activity. They are removed at the end of the operation. Workers are used for the following operations:

• image-level backups for EC2 and RDS
• restore data from an image-level backup
• index EFS 
• retention task

Backups created by workers are sent to a backup repository which uses Amazon S3.    

Workers are based on standard amzn-linux-v2 and the specific Veeam binaries are installed from a dedicated S3 bucket (configuration bucket). They run the following services:

Veeam Data Mover —  retrieves data of protected AWS resources and transfers it to backup repositories. During restore, it transfers backed-up data from backup repositories to the target location.

File-level recovery browser — web service that allows to find and save files and folders of a backed-up EC2 instance to the local machine or to the original location.

Worker are deployed in either the backup account or in the production account. As a best practice, a backup account should be implemented to deploy the VBA appliance and the workers. Additionally a dedicated repository account should be created for the S3 buckets used as backup repositories. This account segmentation is aligned with an increased security posture and helps prevent catastrophic situations in case of an account breach.

For the following operations the workers are deployed in the backup account:

• EC2 image-level backup
• entire EC2 instance restore from image-level backups
• EC2 volume-level restore from image-level backups
• EC2 file-level recovery
• EC2 backup retention tasks
• RDS archived backup

, 

By default, workers are deployed in production accounts for the following operations:

• EFS indexing
• RDS image-level backup
• RDS database restore from image-level backup

However, additional operations can have workers distributed across multiple production accounts:

• EC2 image-level backups
• EC2 instance restore from image-level backups
• EC2 volume-level restore from image-level backups 
• EC2 file-level recovery from snapshots

During deployment operations, VBA assumes a worker deployment role in the account where it needs to deploy the workers. A temporary IAM role is attached to each deployed worker. By default, VBA uses the "Default Backup Restore" role that has all the permissions required to perform data protection and disaster recovery operations.

Workers are created with default profiles based on the size of processed data: 

• Small profile (c5.large) - total EBS volume size < 1024 GB
• Medium profile (c5.2xlarge) - 1024 GB < total EBS volume size < 16 TB
• Large profile (c5.4xlarge) - total EBS volume size > 16 TB
• Archiving profile (c5.2xlarge) is used for transferring data to archive repositories

The default profiles can be customized per region level. However, make sure you understand the impact of changing the worker size on the overall costs for the operation.

Tags can be automatically added to worker instances and the following parameters are available for use:

• %applianceId% - unique VBA appliance ID
• %policyId% - policy ID for which the worker is deployed
• %policyName% - policy name for which the worker is deployed

From networking point of view, you can select per region VPC, subnet and security group where to connect the instances:

VBA uses public IP to communicate with workers which means the selected VPC must have internet gateway and routing tables and security groups should permit access. This behavior can be changed and worker instances can be deployed in a private network by enabling private network deployment functionality in VBA. To ensure your VBA can work in private environment, configure private endpoints as presented here.

Workers are a key architectural component of VBA. Understanding their use cases and how to customize a standard deployment is essential to creating a proper VBA architecture.