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".
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".
Statistics: Posted by RubinCompServ — Mar 11, 2025 5:04 pm
/english-betterindia/media/post_attachments/uploads/2022/05/Sustainable-home-6-1651667217.jpg)
