Backup and DR pricing
This document discusses Cloud Backup and DR pricing details.
Backup and DR offers a consumption based billing model and the billing is based on the following components:
Backup storage charge. The amount of storage consumed by backup images.
Backup usage charge. The amount of usage for backup orchestration and management.
Backup storage charge
Backup and DR enables users to leverage the full richness of Cloud Storage offerings to closely align with backup storage to business criticality of the workload that is being protected.
Backup and DR supports persistent disk, standard storage, nearline storage, coldline storage, and archive storage types. You pay for the amount of storage consumed by backup images in each storage type. For more details on Google Cloud storage pricing, see Cloud storage pricing.
Backup usage charge
The following table lists the SKUs and price points when you use Backup and DR.
|Products / SKUs - Backup||Pricing model||Meter||List price|
|VM data: Cloud VMs1, On-Premises VMs, File Systems||Usage-based||Per GiB-mo of source (front-end) capacity under protection||$0.03 / GiB-month|
|SAP HANA, Oracle, SAP ASE, SAP IQ, SAP MaxDB, IBM Db2||Usage-based||Per GiB-mo of source (front-end) capacity under protection||$0.24 / GiB-month|
|Microsoft SQL Server, MySQL, PostgreSQL, MongoDB, MariaDB||Usage-based||Per GiB-mo of source (front-end) capacity under protection||$0.09 / GiB-month|
|Virtual copies (Test data management)2||Usage-based||Per GiB-mo of total virtual cloned capacity||$0.03 / GiB-month|
1 Both Google Cloud VMware Engine and Compute Engine VMs (including orchestration of Compute Engine snapshots).
2 This includes scenarios where virtual mounts are used for backup testing and/or restores).
How is Backup and DR usage measured?
Backup and DR measures usage based on the actual workload size at the frontend or the size of the workload it is managing. The unit of measurement is gibibyte (GiB). One gibibyte = 1024 * 1024 * 1024 bytes.
If the workload under management reports the volume size for data, Backup and DR takes into account the volume size reported (for example, the usage calculation for VMware will be consistent with the reported size of the VM in vCenter).
If you manage 10 TiB of Oracle data spread across multiple databases, the Backup and DR usage reports 10 * 1024 GiB of data usage.
Usage measurement for agentless Compute Engine
Backup and DR measures usage for Compute Engine VM backup based on the amount of PD storage attached to a Compute Engine VM at the time of backup. Backup and DR allows you to exclude PD volumes from backup. In such instances, only volumes identified to be backed up are used to measure the usage.
For example, if two PD volumes of one TiB and two TiB are attached to a Compute Engine VM and you configure the backup SLT to exclude the 2TiB volume, the usage for the VM is measured to be one TiB.
Additionally, if the 1TiB VM grows or shrinks, Backup and DR measures usage based on the size of the volume at the time of the latest backup.
Usage measurement for agentless Google Cloud VMware Engine
When you manage the entire VMware VM by Backup/DR appliances (all volumes), the usage count is the total allocated size of all managed volumes. If the volumes are thin-provisioned, then thin-provision values are used. If the volumes are thick-provisioned, then the total allocated size is used.
Backup and DR takes into account the size of the managed volumes reported by VMware vCenter. If a VM has been configured with an eight TiB thin-provisioned volume, and it has been allocated two TiB, then two TiB is counted towards usage. When the allocated size increases, the usage amount will increase from the next successful copy after the increase in size.
This method of measurement applies to all VMware backup scenarios. When a Backup and DR agent is installed inside a VM and the workload data within the VM is captured using the Backup and DR agent, the usage calculations are based on Usage measurement for agent-based backup.
Usage measurement for agent-based backup
Backup and DR measures usage for agent-based backup on the actual size of the workload. For example, if an SQL server database backup uses Backup and DR agent and if the sum of data files from an SQL server is five TiB on a seven TiB volume, the usage is measured as five TiB.
Usage measurement for agent-based backup of databases
For Oracle and SQL Server workloads, only the databases protected are counted towards usage. It does not take log files into consideration:
- Oracle. The allocated size of the database files under protection is counted towards usage. The allocated size includes data files and control files.
- Microsoft SQL Server. The total size of all the database files, including .MDF, .LDF, and .NDF files under protection are counted towards usage.
- Database protection with Linux Change Block Tracking (CBT). Backup and DR supports efficient backup of several databases with change block tracking. This backup mode relies on database log and data files to reside on Linux Logical Volume Manager (LVM) managed volumes. For this class of workloads, the usage is measured as the size of the LVM volume under protection. Databases that fall in this category are SAP HANA, SAP ASE, SAP IQ, SAP MaxDB, PostgreSQL, MySQL, MariaDB, and IBM Db2. For a list of databases falling under this category, see Backup and DR support matrix.
- SQL dump-based protection without Linux CBT. Backup and DR supports traditional SQL dump based backups. In this mode, usage is measured as the size of the database as reported by the database at the time of backup.
Usage measurement for virtual copies
Backup and DR measures usage for virtual copies only when a virtual copy of a workload is created. The amount of usage is based on the size of the application at the time of last backup. The most common way to create virtual copies is mount jobs. There are other job types such as prep-mount and reprovision that can also create a virtual copy. Usage charges are prorated based on the time the virtual copy is in use (from the time of the successful mount to the time of its unmounting or deleting).
Consider the example of an SQL server database of size one TiB. This workload incurs a backup usage charge of one TiB. Additionally, consider a virtual copy of this database is provisioned to a test server on the first of the month. On the 15th of the month, the virtual copy is unmounted from the test server at 11 AM. In this scenario, a one TiB virtual copy usage charge of one TiB is incurred every day from first to the 15th. The virtual copy usage for the 15th will only count usage for 11 hours and not for the entire day. The usage amount does not change with additional data written to the virtual copy.
Factors that influence usage measurement
Factors that influence usage measurement in out-of-band scenarios:
- Compressed volumes. When volume is compression enabled, the usage counts the post-compression values. For example, if a two TiB volume has 2.5 TiB of data that is compressed into 1.8 TiB, usage count will be 1.8 TiB, not 2.5 TiB.
- Windows optimized volumes. For Windows optimized volumes, Backup and DR rehydrates the volume for backup, and the usage count will be the rehydrated value. For example, if a one TiB Windows optimized volume contains 800GiB data, when rehydrated for backup ends up as 1.1 TiB, the usage is 1.1 TiB.
- Block sizes. For staging disks, Backup and DR measures usage based on the block size of the staging disk. If the source volume's block size and the staging disk block size match, then the usage values will exactly match the source volume. If the block size used on the staging disk is different from the source volume, then there will be a minor difference because the usage calculation is done on the staging disk.
- Consistency groups. The usage count for a consistency group is the sum of all workload sizes in the consistency group. Workloads are measured individually and summed.
For any questions related to pricing, see Frequently asked questions.