Used space in BEM doesn't match VBR

[RubinCompServ]

We host a vCloud instance and use the Veeam Self-Service portal to provide Backup-as-a-Service for our customers. Customers purchase a certain amount of backup storage from us and we use the BEM to set a quota. After we updated from v12.2 to v12.3, the BEM-reported usage number for one of our customers jumped up by approximately 80 TB, causing their account to report 240TB usage against a 200TB quota. Needless to say, all of their backup jobs failed until we allocated an additional 100TB of (unpaid) backup storage for them. I figured it was a simple issue and opened ticket #07621944 with Veeam support. Imagine my surprise to receive a response that boiled down to: “Yeah, it’s an undocumented bug when using a SOBR with an S3 Capacity Tier. It’s scheduled to be fixed at some point in the future. Sorry about that.”

Veeam keeps hyping their SOBRs and S3 Capacity Tiers - it comes up in literally every conversation pertaining to DR - and we've taken that advice to heart and built a business model around it. And now we've found out that Veeam has a known - and unpublished - bug that affects reporting in the *recommended* configuration, and forces us to provide a storage allocation that can't be reconciled against billing. And when you couple that with the fact that Veeam can't even specify when it will be fixed, I find myself wondering what other land mines are lying in wait for us. I wouldn't think it would be overly complicated for a developer to write a script that will compare the numbers in the BEM database against the numbers in the VBR database, but perhaps the databases are simply too obfuscated to make such a script feasible.

We've made a policy of staying one (minor) version behind the latest release whenever possible, and the only reason we updated at all was because Veeam's only response to a different ticket (#07614370) was “Upgrade to the latest version”. Of course, that forced upgrade brought us a new set of bugs, and served to reinforce our policy of not going to the "latest and greatest".

[PetrM]

Hi David,

Let me take some time to discuss the issue with the support leadership and gather more information about it.

Thanks!

[PetrM]

Hello,

@RubinCompServ
According to our engineering team, the current quota calculation mechanism does not work properly when the Capacity Tier or Archive Tier is used. We plan to address these issues in one of our future releases. So far, we have added the following note to our documentation:

Quota calculation is not currently supported for capacity and archive tiers of scale-out backup repositories.

Thanks!

[RubinCompServ]

@PetrM,

As I said above, that's a pretty hefty bug to just address in "one of [your] future releases". I will note that RnD was able to put together a pretty straightforward script to resolve my issue.

As for the note in the documentation, I think that it's somewhat misleading, as it suggests that the BEM simply won't provide quota calculation for the Capacity and Archive tiers, when the actual case is that it DOES perform a calculation and then combines it with the Production tier. It might be better worded as:

Quota calculation is not currently supported for scale-out backup repositories containing capacity and/or archive tiers .

[PetrM]

David, many thanks for the suggestion! I will discuss it ASAP with our technical writers.

Thanks!