Backup and DR Service 会根据上次成功复制的大小来衡量用量。因此,对于大小为 4 TiB 且每日更改率为 10% 但数据库大小始终为 4 TiB 的 Oracle 数据库,用量计算结果将为 4 TiB。除非工作负载大小发生变化,否则变化率不会直接影响使用量计算。
如果我要保护工作负载及其虚拟机,如何避免支付双重保护费用?
Backup and DR Service 会单独统计 VMware 虚拟机及其工作负载的使用情况,这可能会导致重复统计。如果您使用备份和灾难恢复代理管理在 VMware 虚拟机上运行的 SQL Server 工作负载,并且您还管理整个 VMware 虚拟机,则 SQL 数据库会单独计入,而不会计入虚拟机。在这种情况下,最佳实践是单独管理虚拟机的操作系统卷和驻留在虚拟机上的工作负载。这样可以有效地消除双重保护,从而避免重复统计。
您是仅统计数据库大小,还是在使用情况衡量中纳入日志文件?
Backup and DR Service 仅衡量一致数据库备份所需的托管式数据库文件。日志文件不会计入使用情况衡量范围。
如何验证我的 VMware 虚拟机用量?
VMware 虚拟机的 Backup and DR Service 使用情况测算结果与 vCenter 报告的该虚拟机大小一致。
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;
如何验证我的文件系统用量?
根据工作负载衡量文件系统的备份和灾难恢复服务用量:
Windows - DiskManager 报告的已用文件系统大小
Linux - df - k 报告的已用文件系统大小
针对 Google Cloud VMware Engine 备份服务改用基于节点的定价
基于节点的 Google Cloud VMware Engine 备份价格中包含哪些内容?
价格仅适用于保护 Google Cloud VMware Engine - 整个虚拟机备份。它不包括任何基于代理的备份的备份管理费用,例如 SAP HANA、SQL Server、MySQL 或 Postgres 的应用一致备份的费用。如需估算基于代理的备份的费用,需要每种数据库类型的生产大小。基于代理的备份根据标准 Google Cloud Backup and DR 价格计费。
与基于节点的新价格相比,现有的基于托管式数据许可 (MDL) 的价格如何?
以下示例说明了新版 Google Cloud VMware Engine 备份服务现行价格与新价格之间的差异。
我现有的价格折扣是否适用于新的 Google Cloud VMware Engine 相关备份 SKU?
您现有的价格折扣仍适用于新的 Google Cloud VMware Engine 相关备份 SKU。
我可以选择基于现有托管式数据许可 (MDL) 的价格,还是基于新的节点价格来备份 Google Cloud VMware Engine 虚拟机吗?
今后,对于想要使用Google Cloud 备份和灾难恢复
服务备份 Google Cloud VMware Engine 虚拟机的所有客户,我们将仅支持新的基于节点的定价模式。
我需要做些什么才能改用基于节点的新 Google Cloud VMware Engine 定价模式?
所有现有的 Google Cloud 保护 Google Cloud VMware Engine 工作负载的备份和灾难恢复服务客户都必须将其每台备份/恢复设备更新到 11.0.5 或更高版本,才能采用更新后的定价模式。2023 年 8 月 4 日之后,所有备份设备都升级到 11.0.5 或更高版本后,价格将自动改为基于节点的新价格。
如果我不想从现有的基于托管式数据许可 (MDL) 的定价模型改用新的基于节点的定价模型来备份 Google Cloud VMware Engine 虚拟机,该怎么办?
[[["易于理解","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-08-25。"],[[["\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`"]]