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

Question

Hi Everyone,

We are investigating an Azure Backup storage discrepancy for a Recovery Services Vault and would appreciate your guidance.

Scenario:

• Recovery Services Vault: bak-asco-eastus-003
• Backup Storage (Overview): Cloud-GRS = 211.77 TB
• Protected workload:
  • 77 SQL Databases in Azure VM
    • 8 Azure Virtual Machines
    • Approximate protected data size: ~12 TB

The reported Cloud-GRS backup storage appears significantly higher than the actual protected workload.

Investigation performed:

• Verified the Recovery Services Vault configuration.
• Reviewed all protected backup items.
• Verified backup policies (weekly full, daily differential, transaction log backups every 15 minutes).
• No backup items were found in a retained, suspended, or deleted state.
• Reviewed Azure Cost Analysis.
• Compared this vault with other Recovery Services Vaults protecting a similar number of SQL databases and Azure VMs. Other vaults report significantly lower Cloud-GRS backup storage.
• Backup Reports cannot be used because a Log Analytics Workspace was not configured for the vault.

Question:

Is there any Azure portal, PowerShell, Azure CLI, or REST API method to determine:

• Which backup items are contributing to the reported 211.77 TB of Cloud-GRS backup storage?
• Whether retained recovery points or hidden backup metadata can contribute to this value?
• Any additional troubleshooting steps that can be performed from the customer side before opening a support request?

Any guidance would be greatly appreciated.

Thank you.

Answer 1

Hello Thanvanth Sai Pasupuleti,

Thank you for posting your query on Microsoft Q&A platform.

1. Identifying which backup items contribute to the 211.77 TB

There is currently no way to get a per-item storage breakdown from the vault Overview blade, PowerShell, CLI, or the REST API. The vault-level usages API returns the same aggregate number you're already seeing, and backupUsageSummaries returns only item counts by workload type, not storage.

Reference: Backup Usage Summaries – List.

The supported way to get this breakdown is Backup Reports. The Backup Items tab shows cloud storage consumed at the individual backup-item level and this explicitly covers SQL in Azure VM, so you'll see consumption per SQL database. The Usage tab gives the same view rolled up to the protected VM (billing entity) level.

Reference: View reports for Azure Backup.

I know you mentioned Log Analytics isn't configured, that's the one blocker to resolving this, so I'd suggest setting it up as the first step.

Configure diagnostic settings on the vault to send data to a Log Analytics workspace, choosing Resource specific as the destination table type: Configure Azure Backup reports.

Data begins flowing within about 24 hours, and you don't have to wait for the workbook, you can query CoreAzureBackup directly for BackupItemFrontEndSize, BackupItemProtectionState, PolicyName, and OldestRecoveryPointTime

(CoreAzureBackup table reference).

2. Yes, retained and soft-deleted data does contribute, and this is the most likely explanation

Two documented behaviours are worth checking, because both cause exactly the pattern you're describing:

• If Stop backup → Retain backup data was ever used on an item, the retention range in the policy no longer applies to that data. Per the documentation, "it continues the pricing as is until you remove the data manually" Soft delete for virtual machines.
• While an item is in soft-deleted state, "no recovery points are cleaned on their expiry as per the backup policy." Soft delete is now enforced by default, with a retention window of 14–180 days Configure and manage soft delete.

It's also worth keeping in mind how storage is actually accounted for: consumed storage is the sum of all blocks across all recovery points, not the size of the most recent one. Blocks are only released once every recovery point referencing them expires https://learn.microsoft.com/en-us/azure/backup/manage-recovery-points.

With your policy weekly full, daily differential, and transaction log backups every 15 minutes across 77 databases the accumulated recovery point chain, not the 12 TB source footprint, is what determines the total. That is also the most probable reason your other vaults report much lower numbers despite a similar item count: the difference is usually in retention duration rather than protected size.

3. Steps to try before opening a support case

1. Enable diagnostic settings → Log Analytics on the vault and open Backup Reports → Backup Items.
2. In that tab, filter by the Protection Stopped state — this immediately surfaces any retained items that no longer show up as active.
3. Check the vault's backup items list for soft-deleted entries (shown in red, with no recovery points).
4. Compare the full/differential/log retention days in this vault's policies against the vaults reporting lower storage and confirm SQL compression is enabled on the policy.
5. Review OldestRecoveryPointTime per item. Any recovery point significantly older than the configured retention is a strong indicator of data that isn't being pruned.
6. If index rebuild or reorganize jobs run on these databases, review their frequency — they generate large volumes of transaction log data, which directly inflates 15-minute log backup sizes.

If, after enabling reports, the sum of per-item storage still comes out materially below 211.77 TB, that would point to a genuine accounting discrepancy on the backend, and at that stage a support case with the report export and the vault resource ID would be the right next step.

Hope this help, happy to assist further if anything is unclear.

Thanks,

Suchitra.

Answer 2

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.