Link Search Menu Expand Document


Workers are used by VBG to create backups of workloads 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.

The backup performance within Google Cloud is limited by the disk read speed. To achieve optimal backup performance, a backup worker instance always has a 4TB total disk size or more to process the source instances. If the total disk size of a source instance is below 4TB, VBG will assign additional empty disks to the worker to assure the optimal performance is achieved.

If you want backups to proceed quickly it is a good idea to use a worker profile for this that uses Standard Persistent Disks. Google Cloud does have disk quotas in place that affects the maximum number of backups processed in parallel in the same zone. The maximum number of backups in parallel cannot exceed this quota defined in TB divided by 4.

Worker placement

Workers are deployed as an Ubuntu image and removed once the task that they will perform is finished.

For most operations workers are placed in the same region where the source VM instance resides. 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 VBG documentation.


Workers are given a network interface based on the worker pool settings configured in VBG. 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 VBG Region, the default settings of the VBG Region to launch worker instances and to perform data protection and disaster recovery operations will be used.

Worker Sizes

Below is the default table of used sizes that can be changed within the worker configuration page.

Profile Machine type Purpose Backup Speed
Primary e2-highcpu-8 used while sufficient disk quota is available up to 420 MiB/s (NTFS disks up to 540 MiB/s)
Secondary e2-highcpu-2 used only if you are running out of disk quota up to 210 MiB/s
Archiving e2-standard-4 used for transferring data to archive repositories up to 420 MiB/s

For more details the workers profile capabilities and enhancements, refer to the dedicated sections below.

VM Instance Backup

The default configuration is universal and available in all the Google Cloud regions (e2-highcpu-8). For this configuration, the backup speed is up to 420 MiB/s when the sum of the source disk sizes is less than 5 TB. For NTFS disks the backup speed is up to 540 MiB/s. For better speed consistency and overall performance on the same price level, it’s recommended to use n2d-highcpu-8 as worker size. By changing the worker size to e2-highcpu-16, it is possible to achieve backup speed up to 800 MiB/s. This will require to adjust the performance disk size of the worker by changing the value in the configuration file under /opt/veeam/gcpbackup/ServiceSettings.json.

If the sum of source disk sizes is more than 10 TB, changing the worker size to e2-highcpu-16 (n2d-highcpu-16) allows to achieve backup speed up to 800 MiB/s however this will increase the total price for workers.

"Backup": {
  "TotalHddDisksSize": 10000

VM Instance Archive

The default configuration (e2-standard-4) allows archiving data up to 420 MiB/s. To achieve archive speed up to 500 MiB/s, it is required to change the worker size to e2-standard-8. Be aware that by changing the worker size the total monthly costs will increase.

VM Instance Restore

The default configuration (e2-highcpu-4) allows restoring data up to 340 MiB/s. For better speed consistency and overall performance on the same price level, it’s worth to use n2d-highcpu-4 as worker size. By default, a worker for VM instance restore will use an additional performance disk up to 1500 GB. The disk size can be changed via the configuration file to increase the restore speed.

To restore VM instances with a size of 24 TB or more, it required to change the worker size to e2-highcpu-8. This can be changed in the configuration file /opt/veeam/gcpbackup/ServiceSettings.json.

"HardwareSettings": {
  "Restore": "e2-highcpu-4"

To achieve restore speeds up to 400 MiB/s, the worker size should be set as e2-highcpu-8 and the additional performance disk should be 2048 GB. Be aware that by changing the worker size the total monthly costs will increase.

This can be changed in the configuration file /opt/veeam/gcpbackup/ServiceSettings.json.

"HardwareSettings": {
  "Restore": "e2-highcpu-8"
"Restore": {
  "TotalHddDisksSize": 2048

Cloud SQL Backup & Restore

Because of Google Cloud limitations, it is not possible to backup or restore SQL databases that produces 5 TB backup files or larger. Be aware that most of the Google Cloud import and export database process is done at a speed up to 20 MiB/s.

File-Level Recovery

In case a VM instance has 126 disks or more it is recommended to change the worker size when performing file level recoveries. Veeam recommends to use e2-highmem-4 as a size.

This can be changed in the configuration file /opt/veeam/gcpbackup/ServiceSettings.json.

"HardwareSettings": {
  "Flr": "e2-highmem-4"


By default, the retention process runs on the VBG appliance. It is however possible to move this process to a worker instance. The default configuration for the worker size, in this case, is e2-highcpu-8.

To change this and the worker size, change the following properties in the configuration file /opt/veeam/gcpbackup/ServiceSettings.json to the following settings.

  "BackupRetention": {
    "CreateWorkerRestorePointsThresholdGb": 1
  "HardwareSettings": {
   "Retention": "e2-highcpu-8"

The only exception on retention operations is the deletion of an entire backup chain as this is done on the VBG appliance.

The following are recommendations regarding worker sizes based upon your production infrastructure for retention operations.

Largest Production Instance Worker Size
Less than 8TB e2-highcpu-8
Between 8 and 16TB e2-highcpu-16
Larger than 16TB e2-highcpu-32

Back to top

Copyright © 2022 Solutions Architects, Veeam Software.