Architecture Overview
The Veeam Backup for Google Cloud architecture includes the following components:
- Manages architecture components.
- Coordinates snapshot creation, backup and recovery tasks.
- Controls backup policy scheduling.
- Generates daily reports and email notifications.
To communicate with a backup repository, Veeam Backup for Google Cloud uses Veeam Data Mover — the service that runs on a worker instance and that is responsible for data processing and transfer. When a backup policy addresses the backup repository, the Veeam Data Mover establishes a connection with the repository to enable data transfer.
Important |
Backups are stored in backup repositories in the native Veeam format and must be modified neither manually nor by 3rd party tools, including native Google Cloud capabilities (for example, the Autoclass feature). Otherwise, Veeam Backup for Google Cloud may fail to restore the backed-up data. |
Encryption on Repositories
For enhanced data security, Veeam Backup for Google Cloud allows you to enable encryption at the repository level. Veeam Backup for Google Cloud uses the same encryption standards as Veeam Backup & Replication to encrypt backups stored in backup repositories. To learn what encryption standards Veeam Backup & Replication uses to encrypt its data, see the Veeam Backup & Replication User Guide, section Encryption Standards.
To learn how to enable encryption at the repository level, see Enabling Data Encryption.
Limitations for Repositories
To use a storage bucket as a target location for backups, you must connect to a project in which this bucket resides as described in section Adding Backup Repositories.
Veeam Backup for Google Cloud allows you to store backups in the Standard, Nearline and Archive storage classes. The Coldline storage class is not supported. For more information on storage classes offered by Cloud Storage, see Google Cloud documentation.
Operation | Worker Instance Location | Default Worker Machine Types |
---|---|---|
Creating image-level backups of VM instances | Google Cloud region in which a processed VM instance resides | e2-highcpu-8, with an additional empty standard persistent (pd-standard) disk up to 4000 GB in size |
Creating image-level backups of Cloud SQL instances | Google Cloud region in which a target backup repository of the Standard or Nearline storage class resides (for MySQL instances); Google Cloud region in which a processed Cloud SQL instance resides (for PostgreSQL instances) | e2-highcpu-8 |
Creating image-level backups of Cloud SQL instances using a staging server | Google Cloud region in which a source Cloud SQL instance resides | db-n1-standard-4 |
Creating archived image-level backups of VM instances | Google Cloud region in which a processed VM instance resides | e2-standard-4 |
Creating archived image-level backups of Cloud SQL instances | Google Cloud region in which a target backup repository of the Standard or Nearline storage class resides | e2-standard-4 |
Performing health check for created restore points | Google Cloud region in which a target backup repository of the Standard or Nearline storage class resides | e2-standard-4 |
Applying retention policy settings to created restore points | Google Cloud region in which a backup repository with backed-up data resides | e2-highcpu-8 |
Restoring VM instances | Google Cloud region to which a VM instance is restored | e2-highcpu-4, with an additional empty standard persistent (pd-standard) disk up to 1500 GB in size |
Restoring Cloud SQL instances | Google Cloud region in which a backup repository with backed-up data resides (for MySQL instances); Google Cloud region in which the restored Cloud SQL instance will reside (for PostgreSQL instances) | e2-highcpu-4 |
Restoring individual persistent disks of VM instances | Google Cloud region to which the persistent disks of a processed VM instance are restored | e2-highcpu-4, with an additional empty standard persistent (pd-standard) disk up to 1500 GB in size |
Restoring specific Cloud SQL databases | Google Cloud region in which a backup repository with backed-up data resides (for MySQL databases); Google Cloud region in which the target Cloud SQL instance resides (for PostgreSQL databases) | e2-highcpu-4 |
File-level recovery from cloud-native snapshots | Google Cloud region in which a source VM instance resides | e2-highcpu-4 |
File-level recovery from image-level backups | Google Cloud region in which a backup repository with backed-up data resides | e2-highcpu-4 |
Worker instances are deployed based on worker configurations and profiles. For more information, see Managing Workers.
Important |
For Veeam Backup for Google Cloud to deploy the number of worker instances required for a backup or restore process, you must have enough resource quotas allocated between your projects. To learn how to check your quotas, see Google Cloud documentation. |
Worker Instance Components
A worker instance uses the following components:
- Veeam Data Mover — the service that performs data processing tasks. During backup, Veeam Data Mover retrieves data from snapshots and stores the retrieved data to backup repositories. During restore, Veeam Data Mover transfers backed-up data from backup repositories to the target location.
- File-Level Restore Browser — the web service that allows you to find and save files and folders of a backed-up VM instance to a local machine. The File-Level Restore browser is installed automatically on every worker instance that is launched for file-level recovery.
For more information on recovering files of VM instances with the File-Level Restore browser, see Performing File-Level Recovery.
Security Certificates for Worker Instances
Veeam Backup for Google Cloud uses self-signed TLS certificates to establish secure communication between the web browser on a user workstation and the File-Level Restore browser running on a worker instance during the file-level recovery process. A self-signed certificate is generated automatically on the worker instance when the recovery session starts.