Deployment Planning

The Virtual Server Agent (VSA) supports data protection and recovery for instances deployed on Google Cloud.

Virtualization Components and Terminology

The Virtual Server Agent can be installed on one or more machines, so that those machines can serve as VSA proxies. A VSA proxy manages backup and restore operations for guest instances in your environment, eliminating the need to install agents on guest instances.

The Virtual Server Agent is installed on a Windows instance under the Google Cloud service account that contains the instances to be protected. Google Cloud guest tools must be installed on the VSA proxy machine.

A Google Cloud virtualization client is defined in the CommCell software to connect to each Google Cloud service account.

One or more VSA proxies can be deployed for each Google Cloud service account. All VSA proxies for a Google Cloud service account must be added to the Google Cloud virtualization client.

Deployment Considerations

Tiers Based on Service Level Agreements (SLAs)

Different instances can have different backup and recovery options that are defined in a service level agreement (SLA) for each class of instance. For example:

  • High transaction instances that provide customer application support might require multiple daily backups with the requirement to recover instances quickly.

  • User instances might need the ability to recover specific files and folders on a daily basis.

  • Development and test instances might only need weekly backups or the ability to recover to predefined states.

To manage different SLAs, you can create a separate subclient for each class of instance. Each subclient can have its own storage policy, backup schedule, and recovery options.

Data Recovery Considerations

The frequency of backups should be based on your requirements for data recovery. For example:

  • To determine backup frequency, determine how long the maximum window for potential loss can be. For example, if your policy calls for no more than an hour's work to be lost in the event of an instance failure, hourly backups are required.

  • If immediate recovery is a priority, you can restore a copy of an instance that is frequently updated based on incremental backups.

Sizing, Performance, and Load Balancing

There are no explicit limits on the size of backups, number of instances, or size of instances that can be backed up; but you must ensure sufficient storage. You can configure a subclient to check for sufficient free space in the storage domain before performing a backup.

The following factors can affect backup performance:

  • Size and type of backup: More data means longer backups. The size and number of instance disks affects backup time, and full instance backups take longer than incremental backups. Best practice is to monitor backup operations against operational windows to ensure that instances are backed up within expected times.

  • Network speed and traffic: Backups are faster on high-speed networks and during times when network traffic is low.

  • Application activity: To lessen the impact of backup operations on applications running on instances on the same Google Cloud service account, perform backups when host usage is lower.

  • Number of Virtual Server Agent proxies: Add multiple proxies to a Google Cloud service account to back up multiple instances in parallel; but limit the number of additional proxies to reduce the performance impact on the host.

  • Number of backup streams: You can define multiple streams to run backups and restores in parallel and improve the data transfer rate; but only one data read stream is supported for each disk. For more information, see Streams - Overview.


Create backup schedules for subclients to ensure that backups are performed at regular intervals. To balance full instance protection against the need for more frequent backups, you can schedule regular full backups and more frequent incremental backups. You can recover full instances from full or incremental backups.

When possible, schedule backups for different subclients at different times to avoid competition for resources, and schedule large backup operations during times when the network is less congested.