Usage of Storage for Backup in Azure RRS feed

  • Question

  • Hi,

    I am testing Cloud backup with DPM and one thing I noticed is that unlike DPM, Azure storage utilization is better. For example - If my VM size is 80 GB (Allocated space) and usage inside the OS is 20 GB then Azure is copying only the used data whereas DPM needs 80GB of free space even if used space is 20 GB.

    However, I still see that storage utilization in Azure is more compared to actual data in the machine. My machine has only 25GB of space used, but Azure shows me 2 values and both are more than the actual usage. As per my knowledge, Azure performs compression after data is copied, so my utilization should be less than what actually is used and also not sure why I see 2 different usage at Azure portal when I navigate to protected machine.

    Wednesday, February 5, 2020 10:51 AM

All replies

  • Hi,

    The "Backup Storage" tile in the dashboard shows the storage consumed in Azure, I believe what you see under"Backup Items" is the disk usage value from the DPM server.

    Best regards,

    Blog: LinkedIn:

    • Edited by Leon Laude Wednesday, February 5, 2020 12:32 PM Added image
    Wednesday, February 5, 2020 12:27 PM
  • Hi Leon,

    Thanks, I could not understand why DPM and Azure is showing different usage than actual usage. Server that I am backing up has only 27GB used then why "Backup storage" is showing 36GB and DPM showing 43GB.

    Any idea what is happening at back end ?

    Also, how my billing will be calculated, according to "Backup Storage" or "Backup Items" ?

    Wednesday, February 5, 2020 12:59 PM
  • The price will be calculated based on the disk usage in Azure, that is "Backup Storage".

    For more information regarding the pricing, see:

    Data backed up from Azure Backup Agent, DPM, and Azure Backup Server is compressed and encrypted before being transferred, with compression and encryption is applied the data in the vault is 30-40% smaller, the amount may vary a lot but this is likely why it shows a bigger size in DPM.

    Blog: LinkedIn:

    Wednesday, February 5, 2020 1:24 PM
  • Hi Leon,

    Yes, that's what my confusion is if data is compressed to Azure then why it shoes 36GB space usage whereas actual usage inside OS is 27 GB.

    Also, DPM show even more usage which is 43 GB so from there this extra space is being utilized in Azure and DPM ?

    • Edited by SC2317 Wednesday, February 5, 2020 1:40 PM
    Wednesday, February 5, 2020 1:39 PM
  • If you are using fixed size .VHDs / .VHDXs then DPM will need to allocate the full size of the .VHDs / .VHDXs - not just the used space inside the fixed .VHD /.VHDX files.

    Blog: LinkedIn:

    Wednesday, February 5, 2020 1:42 PM
  • Hi Leon,

    I am backing up VMware virtual machine and its size is 80GB. If DPM, uses allocated storage then it should show 80GB in utilization instead of 43 GB. As far as I know, DPM does not use any compression technology so not sure why there is difference in storage utilization.

    Wednesday, February 5, 2020 1:59 PM
  • No, DPM does not do any compression, but the backup data will be compressed before moved in to the Recovery Services Vault.

    Back to the original question:

    What you see under "Backup Items" is what DPM sees.

    What you see under "Backup Storage" is what is stored in Azure.

    Blog: LinkedIn:

    Wednesday, February 5, 2020 2:22 PM
  • Hi Leon,

    Thanks. Is there a way I can save space in DPM, how about enabling de-duplication on disk used to store backups ?

    Wednesday, February 5, 2020 10:37 PM
  • Yes you may deduplicate the DPM storage, it can save you a lot of disk space, have a look here:

    Deduplicate DPM storage

    Blog: LinkedIn:

    Wednesday, February 5, 2020 10:40 PM
  • Hi Leon,

    Is it possible to get benefit of deduplication on VMware VMDKs used to store backup of machines? I cannot see any document related to that on Microsoft.

    Wednesday, April 8, 2020 9:58 AM
  • The storage can be anything, iSCSI, SAN, vSAN, VHDX, VMDKs.

    Blog: LinkedIn:

    Wednesday, April 8, 2020 10:04 AM
  • Thanks.

    I have opened new thread for this.

    Wednesday, April 8, 2020 10:28 AM