Forum Discussion

LeithTussing's avatar
2 years ago

Capacity licensing calculations are wrong

I was reviewing our capacity-based usage for licensing and looking at the actual reported usage in the report and some of the systems are way off in terms of reported size.  One system in particular is one I just added in yesterday, so it has just the one brand new backup.  It's a Windows 2019 VM running on a Windows 2019 Hyper-V host.  The VHD files on the Hyper-V server show as being 230 GB, backed up on the local media the backup is 175 GB in size, but the capacity usage calculation for it shows 456 GB counted against us for it.

What can cause such a massive discrepancy is reported space usage?  I was about to add in another server, but this incorrectly counted usage has put me too close to our capacity limit I dare not risk adding another system that might also be reported incorrectly pushing us over our limit.

Backup Exec 21.4 with Hotfix 215083

10 Replies

  • Does any of QnA help to answer your query from this article - https://www.veritas.com/support/en_US/article.100015943

    Also, can you check license status in BE home tab. It will show the list of sets 
    that were used for this capacity calculation.

    The set , that shows the descrepancy do you have the job log for it and if you could share it along with the
    screenshot of what size it shows in the capacity calculation page. 

    By default, we allows to exclude 3 backup sets to be excluded from capacity calculation. You can use that as well just in case.

  • I've read through both listed articles and neither explain why I'm seeing what I'm seeing.

    Below is the value from the Licensed Status showing this particular server using 456 GB of storage.

    The backup log for this shows 489696971254 bytes backed up which is 456 GB.

    The server does NOT have 456 GB of data on it.  Adding up all the used data there's only 121 GB of data on the server.  That's 1/4 what BE thinks it's backing up.

    The VHDX files being backed up total 207 GB which is the 121 GB of actual data and expanded blank space as these are dynamic growth VHDX files.

     

     

  • I loaded the backup job definition in BackupExec and drilled down to the Hyper-V system being backed up and clicked on it to get the details.  That screen also pulls up the data size about to be backed up in real time from the system which shows 207 GB total when the drives are combined which matches the visual inspection of the VHDX files.

     

  • If you look at the backup sets from that job - what size do they indicate?
    Also do the backup sets show backed up what you would expect to see (eg backed up what you were expecting to be backed up)

  • Looking at the files in the IMG000009 folder which is where that one is stored it shows the DevX-MIL_D_20131127.vhdx file as being 334 GB in size.  Comparing it to the VHDX file on the Hyper-V host it's a 25 GB file there as seen in the pictures above.  I loaded the massive VHDX file and there and it shows as a 100 GB partition with un-allocated 300GB area (all of our other drives are like this too on all servers where there's an allocated partition but empty space behind it to allow growth in the future if needed but it's not allocated space).  Loading the drive there is only 20 GB of data on the VHDX file.

    BackupExec is doing something bizarre with this particular drive and inflating the VHDX file 13x over what it actually is.

    • Gurvinder's avatar
      Gurvinder
      Moderator

      is there a defrag task running on that VM ? 

      • LeithTussing's avatar
        LeithTussing
        Level 3

        I just checked and there's the default weekly Windows defrag task enabled.  If it's on there it's likely on all of our VMs.

  • Check w/o that defrag running between backups, if the size of backup is the same.
    • LeithTussing's avatar
      LeithTussing
      Level 3

      This was the first time ever this system was backed up using Hyper-V host image backup, the state of defrag info should not have mattered during a first backup with no history of file location/fragmentation.  I already did several follow up test backups of the same system after the first and defrag did not run between those backups and the size comes back this inflated size each time.