The use of
$site = Get-SPSite "http://sharepoint"
UsageInfo-class also includes
DiscussionStorage-field which might differ from 0, i.e. its size is also added to the backup.
What's even more likely is that the size of the backup grows because of Audit logs. Audit logs increase the site collection's (=backup's) size but are not on shown in these records. Audit logs can be managed at
http://sharepoint/_layouts/15/AuditSettings.aspx and viewed at
There might be other exluded content that's not shown with
SPSite.UsageInfo.Storage-field. As already seen by the Audit log example, the definition of
The data of the Storage field is used to enforce storage quotas.
indeed doesn't cover everything. One way to explain what this storage covers is to have a look at your site collection with SharePoint Designer. Quite likely the
Total Storage Used value is pretty close to the value you get with PowerShell.
To cover the further questions: if you wish to decrease the size of Audit log data, I'd recommend to trim the data. Instead of deactivating the audit logging (which, afterall, was activated for a reason and one day can save you from a trouble or two) you could trim the log files to let's say until yesterday.
Here's a PowerShell-script which does the job:
$site = Get-SPSite -Identity http://sharepoint
#To Get Yesterday
$date = Get-Date
$date = $date.AddDays(-1)
#Delete Audit logs
Credits to Salaudeen Rajack.
Monitor the content DB's size before and after the trimming.
To avoid the continuous growing of Audit log, make sure you have a reasonable number of days at your site collection's Audit logging settings at specify the number of days of audit log data to retain. This could be e.g. 30, 60 or 90 days. Also to have some room for the growth of your site collection, you should consider adding more disc space available as it seems you have space for more than 38 GB (which is needed currently) but less than 80 GB.