Overview

VBG uses the following components for the backup process:

• A backup appliance to control backup operations via a service bus and workers
• A set of pub/sub topics to communicate with workers
• Pools of workers used to run backup operations that send data to repositories
• A bucket used for worker provisioning
• A bucket used as a backup repository

This guide is intended to provide best practices around sizing, deploying and using VBG, and assumes you have already read the Veeam Backup for Google documentation.

How backup works

Veeam Backup for Google can protect the following workloads:

• VM instances using cloud-native snapshots and image-level backups
• Cloud SQL instances using cloud-native snapshots and image-level backups

1. Workers are used for VM instances and Cloud SQL image-level backup and archiving. Workers are created to form a worker pool, with the correct networking in-place. VBG can communicate to workers via IPv4 networking.

2. Once deployed workers communicate via traditional networking or via a Pub/Sub topic.

3. The appliance is issues the relevant API calls. Cloud-native snapshots are used for VM instances and Cloud SQL. For image-level backups the worker service starts processing the data at source to make an image-level backup. Snapshots are tagged with encrypted metadata to help identify them.

   for VM Instances

   a. Per disk a disk snapshot is created by the appliance. After the initial snapshot subsequent snapshots are incremental. Snapshots are used to create persistent disks that are mounted to the worker instance.

   b. Data is offloaded to the destination backup repository and stored in the native Veeam format. Workers are released upon backup session completion and if there are no further tasks the worker instance is removed.

   for Cloud SQL

   a. The appliance creates a SQL backup snapshot of the Cloud SQL instance. After the initial snapshot subsequent snapshots are incremental.

   b. If backup is enabled the appliance triggers a SQL export. Data is read by the worker and then offloaded in native Veeam format. Once completed, the worker is released and if there are no further tasks it is removed.

4. VM instances and Cloud SQL databases can be restored by using the source snapshots if applicable, or from the repository data.

Restore Operations

In order to restore over an existing instance the original VM instance will be removed. A new VM instance is created with a new name where the relationship to the old VM id is tracked by VBG.

Networking

By default, VBG deploys worker instances with the same network configurations as those specified for the processed VM instances. However, to optimize infrastructure costs and to ensure better performance of backup and restore processes, you can add worker configurations to specify network settings for each region in which worker instances will be deployed.

---