Backup and DR Service 根据前端工作负载大小来衡量用量。它不会考虑保留的副本数量或保留位置。添加设备以实现灾难恢复目的不会影响 Backup and DR Service SKU 使用情况。
剪枝路径和排除列表对 Backup and DR 结算有何影响？
如果您的文件系统工作负载包含 3 TiB 的数据，并且您使用剪枝路径和排除列表从管理中排除 1 TiB 的文件，同时使用 Backup and DR 代理备份文件系统，那么用量将根据实际管理的数据量（在本例中为 2 TiB）来衡量。
如果您在没有 Backup and DR 代理的情况下备份文件系统（例如使用无代理的整个 VMware/Compute Engine 虚拟机备份），则用量将根据卷的大小（即 3 TiB）来衡量。
我的工作负载的使用次数似乎比昨天报告的要低，这是为什么？
Backup and DR Service 用量基于最近一次成功复制，而不是最大的可恢复副本。工作负载随时间缩小或扩大（无论涉及的变化率是多少）。当工作负载大小缩小时，它会反映在最近一次备份的使用情况读数中。
数据库更改速率对使用情况有何影响？
Backup and DR Service 会根据上次成功复制的大小来衡量用量。
因此，对于一个 4 TiB 的 Oracle 数据库，如果每天的更改率为 10%，但数据库的大小始终为 4 TiB，则用量计算结果为 4 TiB。除非工作负载的大小发生变化，否则更改率不会直接影响使用量计算。
如果我保护工作负载及其虚拟机，如何避免支付双重保护费用？
Backup and DR Service 会分别统计 VMware 虚拟机及其工作负载的用量，这可能会导致重复统计。如果您使用 Backup and DR 代理管理在 VMware 虚拟机上运行的 SQL Server 工作负载，并且还管理整个 VMware 虚拟机，则 SQL 数据库的费用将与虚拟机的费用分开计算。在这种情况下，最佳实践是分别管理虚拟机的操作系统卷和驻留在虚拟机上的工作负载。这样可以有效避免双重保护，从而避免重复统计。
您是仅统计数据库大小，还是将日志文件也纳入使用情况统计？
Backup and DR Service 仅衡量一致的数据库备份所需的受管理数据库文件。它不会将日志文件计入用量。
如何验证 VMware 虚拟机的用量？
VMware 虚拟机的 Backup and DR Service 使用量衡量结果与 vCenter 报告的相应虚拟机大小一致。
服务器上相应虚拟机文件夹中的 du -h *.vmdk 输出与用量计数一致。
如何验证 Oracle 数据库的用量？
Oracle 的 Backup and DR Service 用量衡量标准基于数据库的分配大小。以下是一个用于验证 Oracle 数据库大小的查询示例。
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;
然后减去以下各项：select sum(bytes) free from dba_free_space;
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[[["\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`"]]
