Backup and DR Service pricing
This document discusses Cloud Backup and DR pricing details.
Overview
Backup and DR Service 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 Service 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 Service 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 Cloud Storage pricing, see Cloud storage pricing.
Backup/recovery appliance charge
The backup/recovery appliance runs in a compute instance VM running in a customer-selected project, and the standard compute engine instance charges apply. Backup and DR Service supports the Compute Engine machine types listed in Set up and plan a Backup and DR Service deployment.
Backup usage charge
Each project in Google Cloud has a billing account that is used to define who pays for the usage of Google Cloud resources and APIs in that project. When the backup and DR service is activated in a project then any usage of the four SKUs detailed below will be billed to that project. This is regardless of zones or projects the backup/recovery appliances are located in.
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: Compute Engine VMs, 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) | Usage-based | Per GiB-mo of total virtual cloned capacity | $0.03 / GiB-month |
1 This includes scenarios where virtual mounts are used for backup testing and/or restores.
Pricing for backing up Google Cloud VMware Engine is based on consumption and commitment term; options include on-demand or committed use discounts for one- and three-year terms.
The following table lists the SKUs and price points for protecting Google Cloud VMware Engine ve1-standard-72 nodes and ve1-standard-72 storage-only nodes.
| Products / SKUs - Backup | Pricing model | Meter | Region | Location | List price (on demand) | 1 yr commitment (Monthly payments USD) | 1 yr commitment (Upfront payment USD) | 3 yr commitment (Monthly payments USD) | 3 yr commitment (Upfront payment USD) |
|---|---|---|---|---|---|---|---|---|---|
| VM data: Google Cloud VMware Engine | Node-based | hourly per node | asia-northeast1 | Tokyo | $0.53 | $0.40 | $0.37 | $0.30 | $0.27 |
| Node-based | hourly per node | asia-south1 | Mumbai | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | asia-southeast1 | Singapore | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | australia-southeast1 | Sydney | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | europe-west2 | London | $0.53 | $0.40 | $0.37 | $0.31 | $0.27 | |
| Node-based | hourly per node | europe-west3 | Frankfurt | $0.53 | $0.40 | $0.37 | $0.31 | $0.27 | |
| Node-based | hourly per node | europe-west4 | Netherlands | $0.53 | $0.40 | $0.37 | $0.31 | $0.27 | |
| Node-based | hourly per node | europe-west6 | Zurich | $0.58 | $0.44 | $0.40 | $0.33 | $0.29 | |
| Node-based | hourly per node | europe-west8 | Milan | $0.54 | $0.41 | $0.38 | $0.31 | $0.27 | |
| Node-based | hourly per node | northamerica-northeast1 | Montreal, Qubec, North America | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | northamerica-northeast2 | Toronto, Ontario, North-America | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | southamerica-east1 | Sao Paulo | $0.66 | $0.50 | $0.46 | $0.38 | $0.33 | |
| Node-based | hourly per node | us-central1 | Council Buffs, Iowa, North America | $0.46 | $0.35 | $0.33 | $0.27 | $0.23 | |
| Node-based | hourly per node | us-east4 | Ashburn | $0.46 | $0.35 | $0.33 | $0.27 | $0.23 | |
| Node-based | hourly per node | us-west2 | Los Angeles | $0.50 | $0.38 | $0.35 | $0.29 | $0.25 | |
| Node-based | hourly per node | southamerica-west1 | Santiago | $0.64 | $0.48 | $0.45 | $0.37 | $0.32 | |
| Node-based | hourly per node | asia-south2 | Delhi | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | me-west-1 | Tel Aviv | $0.51 | $0.39 | $0.36 | $0.29 | $0.26 | |
| Node-based | hourly per node | europe-west-12 | Turin | $0.54 | $0.41 | $0.38 | $0.31 | $0.27 |
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
The pricing for Google Cloud VMware Engine is calculated based on the Google Cloud VMware Engine ve1 nodes and Google Cloud VMware Engine ve1 storage-only node.
For Google Cloud VMware Engine ve1 node
The pricing is calculated based on the number of ESXi nodes that are being protected. A ESXi node is considered to be protected if one or more of VMs attached to it are being protected by Backup and DR Service.
Below is an example that demonstrates the billing process for Google Cloud VMware Engine:
Price to backup a single Google Cloud VMware Engine node (VM backups only) in us-central1 region for a month =
(List price to backup the node/ hour) X (No. of hours in a day node is active) X (No. of days in a month).
Considering the Google Cloud VMware Engine node is active for 24 hours, there are 30 days in a month, and the price to backup a node will be $0.46 X 24 X 30 = $331 USD.
Pricing is only for protecting Google Cloud VMware Engine—whole VM backups. It does not include backup management charges for any agent-based backups, such as charges for application consistent backups for SAP HANA, SQL Server, MySQL, Postgres, File System agents, etc. To estimate charges for agent-based backups, refer to Usage measurement for agent-based backup.
For Google Cloud VMware Engine ve1 storage-only node
The pricing for protecting a Google Cloud VMware Engine ve1 storage-only node is determined by the number of Google Cloud VMware Engine ve1 storage-only nodes added to a cluster that has at least one or more Google Cloud VMware Engine ve1 protected nodes.
If you have a cluster with Google Cloud VMware Engine ve1 protected nodes and you add Google Cloud VMware Engine ve1 storage-only nodes to the same cluster, all of the storage-only nodes in the cluster will be considered protected by default and you will be charged for protecting all of them. You cannot exclude protection for Google Cloud VMware Engine ve1 storage-only nodes in a cluster that has at least one or more Google Cloud VMware Engine ve1 protected nodes.
For example, consider you have an existing cluster of 20 nodes and you are protecting 10 of them using Backup and DR service. If you add 3 storage-only nodes to the cluster, then all 3 storage-only nodes will be considered protected, and you will be charged for protecting 10 + 3 = 13 Google Cloud VMware Engine ve1 nodes.
If you are not protecting any Google Cloud VMware Engine ve1 nodes on a cluster, Google Cloud VMware Engine v1 storage-only nodes cannot be protected in that case.
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 actual used size of the database under protection, using the following queries:
Db2: call get_dbsize_info(?,?,?,-1);
MariaDB: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='
'; MySQL: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='
'; PostgreSQL: SELECT pg_database_size('$db');
SAP ASE: sp_spaceused;
SAP IQ: sp_iqdbsize * block_size;
SAP HANA: select sum(TOTAL_SIZE) from sys_databases.M_VOLUME_FILES where file_type='DATA'
SAP MaxDB: dbmcli -d $DBSID $MAXDB_KEY info DATA
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 starting 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. As new backups are performed, the amount of usage is updated to reflect the current application size. The most common way to create virtual copies is with 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, measured in 1-hour increments).
Consider the example of an SQL server database of size 500 GiB. Backups of this database incurs a backup usage charge of 500GiB. Additionally, consider a virtual copy of this database is provisioned to a test server at noon on the first of the month from the most recent backup. On the 10th of the month the source database shrinks to 400GiB. On the 20th of the month, the virtual copy is unmounted from the test server at 11 AM. In this scenario, a virtual copy usage charge of 500 GiB is incurred for 12 hours on the 1st, and 24 hours a day every day from 2nd to the time of the backup on the 10th. The virtual copy usage charge changes to 400GiB on the 10th (at the time of the backup) and continues until the 20th of the month. The virtual copy usage for the 20th 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.
What's next
For any questions related to pricing, see Frequently asked questions.