When is a workload considered to be under management by Backup and DR Service?
Backup and DR Service billing (also called SKU usage) considers any workload
with at least one un-expired backup using the service. Backup images can be
retained in a snapshot or OnVault pool for extended periods of time (years)
for compliance purposes when the source workload is no longer actively
being protected.
Does backup compression impact usage?
The compression achieved by the system in snapshot and OnVault pools
doesn't affect the usage measurement, as the usage count is based on the
frontend workload size and not the backend storage consumption.
How does replication between backup/recovery appliances affect usage?
Backup and DR Service measures usage based on frontend workload size. It does not
take into account how many copies are retained or where they are retained.
Adding an appliance for DR purposes won't affect Backup and DR Service SKU usage.
How do prune paths and exclude lists affect Backup and DR billing?
If your file system workload has 3 TiB of data, and you use prune paths and
exclude lists to eliminate 1 TiB of files from management, and you use
Backup and DR agent to back up the file system, then the usage is
measured based on the actual amount of data managed, which in this example is 2 TiB.
If you back up the file system without the Backup and DR agent (such as with
agentless whole VMware/Compute Engine VM backup), then the usage is measured based on
the size of the volume(s), which is 3 TiB.
Usage count for my workload seems to be lower than what it reported yesterday, why is that?
Backup and DR Service usage is based on the most recent successful copy, not
the largest recoverable copy. Workloads shrink or expand over a time
(irrespective of the change rates involved). When the workload size shrinks,
it reflects on the usage reading from the most recent backup.
How does the database change rate affect usage?
Backup and DR Service measures usage based on the size of the last successful copy.
So for a 4 TiB Oracle database with a 10% daily change rate, but the size of the
database is always 4 TiB, the usage calculation will be 4 TiB. Unless the size
of the workload changes, the change rate does not directly impact the usage
calculation.
How do I avoid paying for double-protection if I protect a workload and its VM?
Backup and DR Service counts usage for a VMware VM and its workloads
separately, which can lead to double counting. If you manage a SQL Server
workload running on a VMware VM using the Backup and DR agent and if
you also manage the entire VMware VM, then the SQL database is counted
separately from and in addition to the VM.
The best practice in such scenarios is to manage the OS volume of the VM and the
workloads residing on the VMs separately. This effectively eliminates double
protection and thus double counting.
Do you count only the database size or do you include the log files in usage measurement?
Backup and DR Service measures only the managed database files that are needed for
a consistent database backup. It does not count log files towards usage measurement.
How do I verify my usage for VMware VMs?
Backup and DR Service usage measurements for VMware VMs are consistent with the
vCenter reported size for that VM.
du -h *.vmdk output from the appropriate VM folder on the server
matches the usage count.
How do I verify my usage for Oracle database?
Backup and DR Service usage measurements for Oracle are based on the allocated
size for the database. Here is a sample query to verify the Oracle database size.
select (d.total + c.total) total from (select sum(bytes) total from v$datafile) d, (select sum(block_size*file_size_blks) total from v$controlfile) c;
Then subtract the following: select sum(bytes) free from dba_free_space;
How do I verify my usage for file systems?
Backup and DR Service usage measurements for file system based on workloads:
Windows - used file system size reported by DiskManager
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eBackup and DR Service pricing is based on the frontend workload size, not the backend storage consumption or the number of copies retained, and any workload with at least one unexpired backup is considered under management.\u003c/p\u003e\n"],["\u003cp\u003eUsage measurement considers the most recent successful copy, not the largest recoverable copy, and shrinks or expansions in workload size will affect usage calculations.\u003c/p\u003e\n"],["\u003cp\u003eManaging a VMware VM and its workloads separately can prevent double counting of usage, as the service counts them independently; managing only the OS volume of the VM and its workloads individually is the recommended practice.\u003c/p\u003e\n"],["\u003cp\u003eThe new reporting system, based on Cloud Monitoring, Cloud Logging, and BigQuery, offers more comprehensive reporting than the existing report manager, which will be deprecated by April 20, 2024, and only CSV export of historical reports will remain after this date.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Cloud VMware Engine backups will switch to node-based pricing, and customers must upgrade to appliance version 11.0.5 or later by August 4, 2023, to transition to this new pricing model.\u003c/p\u003e\n"]]],[],null,["# Frequently asked questions about pricing for Backup and DR Service pricing\n\nWhere can I find information about Backup and DR Service pricing?\n: Backup and DR Service pricing information is detailed on the\n [Backup and DR Service pricing page](/backup-disaster-recovery/pricing).\n\nWhen is a workload considered to be under management by Backup and DR Service?\n: Backup and DR Service billing (also called SKU usage) considers any workload\n with at least one un-expired backup using the service. Backup images can be\n retained in a snapshot or OnVault pool for extended periods of time (years)\n for compliance purposes when the source workload is no longer actively\n being protected.\n\nDoes backup compression impact usage?\n: The compression achieved by the system in snapshot and OnVault pools\n doesn't affect the usage measurement, as the usage count is based on the\n frontend workload size and not the backend storage consumption.\n\nHow does replication between backup/recovery appliances affect usage?\n: Backup and DR Service measures usage based on frontend workload size. It does not\n take into account how many copies are retained or where they are retained.\n Adding an appliance for DR purposes won't affect Backup and DR Service SKU usage.\n\nHow do prune paths and exclude lists affect Backup and DR billing?\n\n: If your file system workload has 3 TiB of data, and you use prune paths and\n exclude lists to eliminate 1 TiB of files from management, and you use\n Backup and DR agent to back up the file system, then the usage is\n measured based on the actual amount of data managed, which in this example is 2 TiB.\n\n If you back up the file system without the Backup and DR agent (such as with\n agentless whole VMware/Compute Engine VM backup), then the usage is measured based on\n the size of the volume(s), which is 3 TiB.\n\nUsage count for my workload seems to be lower than what it reported yesterday, why is that?\n\n: Backup and DR Service usage is based on the most recent successful copy, not\n the largest recoverable copy. Workloads shrink or expand over a time\n (irrespective of the change rates involved). When the workload size shrinks,\n it reflects on the usage reading from the most recent backup.\n\nHow does the database change rate affect usage?\n\n: Backup and DR Service measures usage based on the size of the last successful copy.\n So for a 4 TiB Oracle database with a 10% daily change rate, but the size of the\n database is always 4 TiB, the usage calculation will be 4 TiB. Unless the size\n of the workload changes, the change rate does not directly impact the usage\n calculation.\n\nHow do I avoid paying for double-protection if I protect a workload and its VM?\n\n: Backup and DR Service counts usage for a VMware VM and its workloads\n separately, which can lead to double counting. If you manage a SQL Server\n workload running on a VMware VM using the Backup and DR agent and if\n you also manage the entire VMware VM, then the SQL database is counted\n separately from and in addition to the VM.\n The best practice in such scenarios is to manage the OS volume of the VM and the\n workloads residing on the VMs separately. This effectively eliminates double\n protection and thus double counting.\n\nDo you count only the database size or do you include the log files in usage measurement?\n\n: Backup and DR Service measures only the managed database files that are needed for\n a consistent database backup. It does not count log files towards usage measurement.\n\nHow do I verify my usage for VMware VMs?\n\n: Backup and DR Service usage measurements for VMware VMs are consistent with the\n vCenter reported size for that VM.\n\n`du -h *.vmdk` output from the appropriate VM folder on the server\nmatches the usage count.\n\nHow do I verify my usage for Oracle database?\n: Backup and DR Service usage measurements for Oracle are based on the allocated\n size for the database. Here is a sample query to verify the Oracle database size.\n\n`select (d.total + c.total) total from (select sum(bytes) total from v$datafile) d, (select sum(block_size*file_size_blks) total from v$controlfile) c;`\n\nThen subtract the following: `select sum(bytes) free from dba_free_space;`\n\nHow do I verify my usage for file systems?\n: Backup and DR Service usage measurements for file system based on workloads:\n\n - Windows - used file system size reported by DiskManager\n - Linux - used file system size reported by `df - k`"]]
