백업 및 DR 서비스 청구 (SKU 사용량이라고도 함)는 서비스를 사용하여 만료되지 않은 백업이 하나 이상 있는 워크로드를 고려합니다. 소스 워크로드가 더 이상 활성 상태로 보호되지 않는 경우 규정 준수 목적으로 백업 이미지를 스냅샷 또는 OnVault 풀에 장기간 (수년) 보관할 수 있습니다.
백업 압축이 사용에 영향을 미치나요?
스냅샷 및 OnVault 풀에서 시스템이 달성한 압축은 사용량 측정에 영향을 미치지 않습니다. 사용량은 백엔드 스토리지 소비가 아닌 프런트엔드 워크로드 크기를 기반으로 하기 때문입니다.
백업/복구 어플라이언스 간 복제가 사용량에 어떤 영향을 미치나요?
백업 및 DR 서비스는 프런트엔드 워크로드 크기를 기준으로 사용량을 측정합니다. 보관된 사본 수나 보관 위치는 고려하지 않습니다.
DR 목적으로 어플라이언스를 추가해도 백업 및 DR 서비스 SKU 사용량에는 영향을 미치지 않습니다.
경로 정리 및 제외 목록은 백업 및 DR 청구에 어떤 영향을 미치나요?
파일 시스템 워크로드에 3TiB의 데이터가 있고, 가지치기 경로와 제외 목록을 사용하여 관리에서 1TiB의 파일을 제외하고, Backup and DR 에이전트를 사용하여 파일 시스템을 백업하는 경우 사용량은 관리되는 실제 데이터 양을 기준으로 측정됩니다. 이 예에서는 2TiB입니다.
백업 및 DR 에이전트 없이 파일 시스템을 백업하는 경우 (예: 에이전트 없는 전체 VMware/Compute Engine VM 백업) 사용량은 볼륨 크기(3TiB)를 기준으로 측정됩니다.
워크로드의 사용량이 어제 보고된 것보다 낮은 것 같습니다. 왜 그런가요?
백업 및 DR 서비스 사용량은 복구 가능한 가장 큰 사본이 아닌 가장 최근에 성공한 사본을 기준으로 합니다. 시간이 지남에 따라 워크로드가 축소되거나 확장됩니다(관련 변경률과 무관). 워크로드 크기가 줄어들면 가장 최근 백업의 사용량 읽기에 반영됩니다.
데이터베이스 변경률은 사용량에 어떤 영향을 미치나요?
백업 및 DR 서비스는 마지막으로 성공한 복사본의 크기를 기준으로 사용량을 측정합니다.
따라서 일일 변경률이 10% 이지만 데이터베이스 크기가 항상 4TiB인 4TiB Oracle 데이터베이스의 경우 사용량 계산은 4TiB가 됩니다. 워크로드의 크기가 변경되지 않는 한 변경률은 사용량 계산에 직접적인 영향을 미치지 않습니다.
워크로드와 VM을 보호하는 경우 이중 보호 비용을 지불하지 않으려면 어떻게 해야 하나요?
백업 및 DR 서비스는 VMware VM과 해당 워크로드의 사용량을 별도로 집계하므로 중복 집계가 발생할 수 있습니다. 백업 및 DR 에이전트를 사용하여 VMware VM에서 실행되는 SQL Server 워크로드를 관리하고 전체 VMware VM도 관리하는 경우 SQL 데이터베이스는 VM과 별도로 VM에 추가하여 계산됩니다.
이러한 시나리오에서 권장사항은 VM의 OS 볼륨과 VM에 상주하는 워크로드를 별도로 관리하는 것입니다. 이렇게 하면 이중 보호가 효과적으로 제거되어 중복 집계가 방지됩니다.
데이터베이스 크기만 계산하나요 아니면 사용량 측정에 로그 파일도 포함하나요?
백업 및 DR 서비스는 일관된 데이터베이스 백업에 필요한 관리 데이터베이스 파일만 측정합니다. 로그 파일은 사용량 측정에 포함되지 않습니다.
VMware VM의 사용량을 어떻게 확인하나요?
VMware VM의 백업 및 DR 서비스 사용량 측정은 해당 VM에 대해 vCenter에서 보고된 크기와 일치합니다.
du -h *.vmdk 서버의 적절한 VM 폴더의 출력이 사용량과 일치합니다.
Oracle 데이터베이스 사용량을 어떻게 확인할 수 있나요?
Oracle의 백업 및 DR 서비스 사용량 측정은 데이터베이스에 할당된 크기를 기반으로 합니다. 다음은 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"]],["최종 업데이트: 2025-09-04(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`"]]