Backup topcy direct to S3 (Wasabi) - used space > backup size

[leviu]

We have a customer that does backup copies directly to Wasabi S3 (no SOBR).
They are complaining that their storage usage displayed in Veeam and Wasabi UI does not reflect that "Backup size" Veeam is reporting that is stored in Object Storage for that job.

Under Home -> Backups -> Object Storage (Copy) -> Properties on the job - shows 3.16 TB Backup size (on the bottom of the window)
Backup infrastructure -> Backup repositories - > Wasabi repo shows 3.8 TB used
Wasabi shows 3.9 TB (data point for yesterday it will probably show 3.8 TB tomorrow)

It is a fresh bucket made months ago just for Veeam buckets and is not used by anything else.
Repo is configured with 14 day immutability,
Backup copy job is set to 90 days.
There is NO "deleted" storage that is eating up the storage allocation in Wasabi.

We had their bucket limit (in Veeam) at 4TB and requested they increase to 5TB since at 4TB backups would occasionally fail.
Customer requested to show them data on their backup sizes. I can't present this data as its incoherent and I don't understand where the size difference comes from.

[Mildur]

Hello Leviu

Please ask your customer to open a support case. We cannot analyze such differences over a forum post. There may be be orphaned objects on the bucket.
Something which you also should be aware, Veeam console displays the data as TiB. Wasabi may use TB. But it wouldn't explain the difference your customer sees.

Best,
Fabian

[leviu]

Thanks Fabian.
Case number 06252368.

I see that lowlander mentioned that its TiB for Object Storage: object-storage-f52/object-storage-in-ti ... 82488.html
Despite the UI saying TB and not TiB.
This still does not explain the discrepancy though.

[Mildur]

Thank you.
I replaced the contract number (#02) with the case number (#06)

Yes, we are aware of it. It can be confusing.
But it's not that easy to change it. Those values are displayed on multiple places in our product.

Best,
Fabian

[leviu]

The bottom line "answer" was: immutable storage.
It does funny things to storage capacity and there seems to be no way to predict/calculate how much.

Customer isn't going to be happy with this.
We are not happy with this - how are we supposed to calculate storage costs without knowing how much immutability will eat up.
This is a customer with small sizes. What happens where there are 100TB and a 5 TB discrepancy due to immutability - can't scrub that under the carpet exactly.

[tyler.jurgens]

Looks like you ran into "block generation" on your immutable bucket.

You can calculate this for your customers by adding *at max* 10 days of incremental point retention to your jobs. Eg: Calculate your backup size for whatever retention policy you put in place, then add 10 days of incremental backups to it. That would give you the maximum amount of storage you would consume.

Charge the customers based on your S3 bucket size. If/when customers notice the discrepancy, link to the Veeam documentation and advise this is what happens.

[Mildur]

Currently we are researching how we can size storage requirements for capacity tier and direct to object storage when immutability is involved. After we confirmed and verified our calculations, we plan to document it in the user guide and incorporate it to the calculators.

Best,
Fabian