Showing posts with label EFS. Show all posts
Showing posts with label EFS. Show all posts

Thursday, November 28, 2024

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. 




Wednesday, November 6, 2024

Veeam Backup for AWS: Comprehensive Cloud Data Protection

In today's cloud-dependent world, data protection is essential for maintaining business continuity. Veeam Backup for AWS (VBA) offers an AWS-native, highly adaptable solution designed to protect, manage, and recover data within AWS environments. Its main purpose is to help organizations address the unique data protection needs of AWS workloads, ensuring that cloud data remains resilient against threats like accidental deletion, cyberattacks, or service interruptions.

Key Components of Veeam Backup for AWS

  1. Automated Backup and Recovery: Veeam allows for fully automated backup processes, supporting Amazon EC2, RDS, Dynamo DB, Redshift, EFS, FSx and VPC. With policies and schedules, users can customize backups to fit business needs and ensure their critical data is consistently protected.

  2. Cost Optimization: Veeam uses Amazon S3 and its various storage classes, such as Glacier and Glacier Deep Archive, to optimize storage costs. Users can automatically tier their data to lower-cost storage options, making cloud backups more affordable without sacrificing accessibility.

  3. Immutability and Security: Leveraging Amazon S3 Object Lock, Veeam ensures that backups remain immutable, providing a strong defense against ransomware and other cyber threats. This feature prevents any changes or deletions to stored data within a specified timeframe, securing it from unauthorized access or malicious attacks.

  4. Cross-Region and Cross-Account Recovery: In case of an outage or disaster, Veeam enables cross-region and cross-account recovery, allowing users to restore data quickly and securely across different AWS accounts or regions, thereby meeting stringent recovery objectives.

  5. User-Friendly Interface and Self-Service: The solution includes a streamlined interface that simplifies backup setup and monitoring. Additionally, self-service recovery options allow users to restore their data with minimal intervention, enabling faster response times in critical situations.

Starting with version 7.0, Veeam Backup for AWS is part of the Veeam Backup & Replication (VBR) solution. AWS Plug-in for Veeam Backup & Replication extends the Veeam Backup & Replication functionality and allows you to add backup appliances to Veeam Backup & Replication. The entire lifecycle of VBA is managed from VBR through AWS Plug-in. 
Deployment, update and management of VBA is done from VBR console. Currently you can still deploy VBA from AWS marketplace, connect it to VBR and upgrade it to the latest version. However this process is deprecated and only VBR console should be used to manage VBA. One or multiple VBA appliances can be managed from the same VBR server. 

Additionally, Veeam ONE can offer enhanced monitoring and reporting capabilities for VBA by collecting date about protected AWS resources. 

By combining these components, Veeam Backup for AWS provides an end-to-end backup and disaster recovery solution tailored for AWS cloud environments, balancing security, cost, and ease of use. 

In the following posts we will take a deeper look at Veeam Backup for AWS architecture and operations.