Recovery Services Vault showing 211.77 TB Cloud-GRS backup storage for ~12 TB protected workload

Hello Thanvanth Sai Pasupuleti,

Greetings! Thanks for raising this question in the Q&A forum.

The root cause of this kind of discrepancy is almost always that the number shown against the "protected workload" (roughly 12 TB) is the front-end data size of the latest full backup, while Cloud-GRS storage reflects the full retained footprint across every recovery point currently held under your policy, that is every weekly full, every daily differential, and every 15-minute transaction log backup, each stored as incremental blocks, multiplied by however long your retention duration is. With 77 SQL databases generating log backups every 15 minutes, that recovery point chain grows very quickly, and if retention is set to months or years, or if a log chain was ever broken and Azure Backup had to retain a longer chain than expected to remain restorable, the stored total can legitimately end up many times larger than the front-end size. Soft-deleted items can also silently add to this even though they don't show in the normal protected items list, since Azure Backup retains soft-deleted backup data for 14 extra days at no charge, but it still counts toward the number shown on Overview during that window.

Check for soft-deleted or excluded items first

In the vault, go to Backup items, then use the Show deleted items or Include soft-deleted items filter toggle, depending on your portal version. Items deleted and stopped with retain-data still hold their recovery points and contribute to the 211.77 TB figure even though your review of "retained, suspended, or deleted" items may not have surfaced them if you were only looking at the default active item list.

Confirm the vault-level number itself with the Usages API

This validates the portal figure independently and confirms which replication type is actually driving the number.

az rest --method get --url "https://management.azure.com/subscriptions/<subId>/resourceGroups/<rgName>/providers/Microsoft.RecoveryServices/vaults/bak-asco-eastus-003/usages?api-version=2023-04-01"

Look at GRSStorageUsage in the response, the value is in bytes and should match the 211.77 TB shown on Overview.

Enable diagnostic settings now to get a per-item breakdown going forward

There is currently no portal, CLI, or REST API call that returns per-item storage consumption without a Log Analytics workspace, since that breakdown is only emitted through Azure Backup's diagnostic events. Enable it now.

• Go to the vault, select Diagnostic settings, then + Add diagnostic setting.
  • Select Resource specific as the destination mode.
    • Select at minimum Core Azure Backup Data, Addon Azure Backup Storage Data, and Addon Azure Backup Protected Instance Data.
      • Send it to a Log Analytics workspace.
      This does not backfill history, but within roughly 24 to 48 hours you will be able to run this KQL query to break the total down by backup item:

                  CoreAzureBackup
      

| where OperationName == "BackupItem" | distinct BackupItemUniqueId, BackupItemFriendlyName | join kind=leftouter ( AddonAzureBackupStorage | where OperationName == "StorageAssociation" | summarize arg_max(TimeGenerated, *) by BackupItemUniqueId | project BackupItemUniqueId, StorageConsumedInMBs, ResourceId ) on BackupItemUniqueId | project BackupItemUniqueId, BackupItemFriendlyName, StorageConsumedInMBs, ResourceId | sort by StorageConsumedInMBs desc ```

        This will show you exactly which of the 77 databases or 8 VMs is driving the number, which is normally impossible to see without Log Analytics.
        
        **Review the retention policy math while you wait for data to populate**
        
        Open each backup policy applied to these SQL items and check the weekly full retention duration, the differential retention duration, and how long transaction log recovery points are kept. If any of these were set to multi-year retention, or if a long-term retention (LTR) rule was applied broadly, that alone can explain a 15 to 20x multiplier between front-end size and stored size, which is roughly the ratio you are seeing here.
        
        **Escalate to Azure Support if the breakdown still doesn't explain it**
        
        Archive-tier storage consumption is not exposed per item in Backup Reports or Log Analytics today, only at the vault level, so if you have archive tier enabled and the Log Analytics breakdown in step 3 still leaves an unexplained gap, this next part has to come from the backend. Open a support request:
        
           - Issue type: **Technical**
           
              - Service: **Recovery Services vaults**, then **Backup**
              
                 - Problem type: **Backup storage consumption or reporting issue**
                 
                 Include the vault name `bak-asco-eastus-003`, the resource ID, the Usages API output from step 2, and the KQL results from step 3 once available, this lets the backend team correlate quickly instead of needing to re-run the same discovery you already did.
                 

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.