Quotas

[wessexit]

Hi,

Are there any plans to introduce quotas into the Office 365 backup product similar to the cloud connect tenant quotas in VBR?

Thanks,

Richard.

[nielsengelen]

There are currently no plans for this. How would you like to see this implemented if we would add it? Or is this already aimed for the upcoming SharePoint & Onedrive for Business support?

[wessexit]

It doesn't have to be particularly sophisticated... you could simply add a quota feature to the repository. Generally a client would only have one Office 365 tenant (or "Organisation" as defined in the Veeam Backup for O365 GUI).

A more advanced approach would be to add the concept of a customer (similar to a "tenant" in VBR), assign the quota to the customer, then associate Organisations (office 365 tenants) to that customer.

I don't recall seeing any mention of quotas in the threads about the upcoming release including SharePoint & OneDrive support, but you'd probably be in a better position to advise...

Thanks,

Richard.

[Mike Resseler]

Richard,

Just to be sure. You mean something like: Each customer can have a maximum backup of x GB? Or similar? Or a Quota per organization?

[wessexit]

I think the use case where a customer has more than one organisation (Office 365 tenant) is pretty unlikely in which case it doesn't matter whether the quota is applied to the customer or the organisation. If a customer can only have one organisation (Office 365 tenant) though then there probably isn't much point in having a separate customer entity within the application...

[exigo]

Hi

Unfortunately, there is no way in the current version to put a quota on an Office 365 repository. Is this planned in an upcoming release? I think this is a mandatory feature for service providers.

[nielsengelen]

Quota support won't be available in the upcoming version 4 but your feedback is noted. Could you tell us a bit more on how you would like to see this implemented? On a per account setting, per repository...?

[Mike Resseler]

By the way, I kind of feat this is a bad idea, even for service providers. Backup of O365 data is not like backup of a VM. In case you hit your quota, basically the latest backup of that VM can not be sent to the service provider anymore. With O365 it is different and you will reach a state where you will have restore points that have partially email, files, sites... So after you hit a quota, you will have real issues restoring data because there will always be missing information in your mailbox, OneDrive folder or Site.

[isolated_1]

Please add my vote to have some sort of quota feature to the Veeam Office 365 backup product. As a service provider, this feature is a must for us. We sell to clients based on storage consumption that they purchase from us. We don't care what they backup with Veeam 365. Without a way to put some sort of limit per organization, this makes it very hard on us.

Mike Resseler makes a valid point regarding the partial files and whatnot but I'm sure something can be worked out. Even if it's something basic like sending out warning level threshold alerts when capacity is at 75% or something.

[nielsengelen]

Your request is noted Simon. Thanks for the feedback.

[pnikies]

+1
As a service provider, I also would like a quota per repository.
it is my responsibility to take care of the free space and alert my customers when they almost reach their quota.
Thanks for your great job !

[AlexHeylin]

+1
As an SP I also vote for much better properly multi-tenant rework of VBO365, to include quotas. Currently the system only supports multiple tenants on a repo = tenant system, and quotas requires running VBO365 in a VM and provisioning lots of disks so one repo = one disk. Then the repo will run out of space when the tenant hits their quota. This is all rather clunky, and unnecessarily complicated to set up and manage, especially increasing disk space to enlarge a tenant quota. If VBO365 was quota aware, repos could be folders sat in much larger disks and VBO365 could be more proactive about monitoring and alerting on tenant quota usage.

To address the point about partial full backups when the quota limit is reached - that's down to the application to handle that in a good way. It'll only have partial backups if you let it write partial backups. I don't think anyone is recommending that clients are allowed to routinely sit on their quota and use it like a retention policy. I'm certainly not suggesting that. I'm suggesting quotas are observed natively by VBO365, and if that means a tenant backup completely refuse to run when they hit their quota - that's absolutely fine with us. It puts us in a great position to force a discussion with the tenant about usage and sell more storage, or rework the scope / retention to better suit them.

Thanks.

[Mike Resseler]

Can you start by using this?

https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=50

It is a soft limit, meaning that we will go over the limit to finish the job, but then a new job is not started

[AlexHeylin]

Hi Mike,
We can't as we're not using object storage. Did I miss something here?

[Mike Resseler]

Alex,

Unfortunately, we don't have quotas on the Jet DB repositories, and I don't foresee this will happen fast, as it is a database. We do limit the database to a certain amount of space but then create a new one. Unfortunately, that is not what you need.

As a service provider, are you considering object storage? The reason I ask is that for service providers who are growing their business, only object storage repository will be able to scale enough for the future. The JET DB repository is not a bad solution, but is not intended for those very large scale deployments when it comes to resource usage

[AlexHeylin]

Hi Mike,
We have not given serious consideration to using object storage for VBO365. As we've got "free" (as in already paid for) disks we're spinning ourselves, paying out cash to someone else to store data we could store would not be popular with management.

As we have to use a repo per tenant anyway (due to the way VBO365 attempts to support multitenancy), why would JET not be able to cope?
Sure, if you threw every tenant into a single repo that could give problems of scale, though your DB size limit should help with that anyway. However putting all tenants in one repo would tie all tenants to a single policy which we don't want, and would also mix up all their mail in the DBs which could easily come back and bite us at some point.

We're not using VBO365 for email archiving (we've seen what can happen there with badly implemented / unmanaged JET!), we're typically keeping 30 days of snapshots. Given that then splits to a JET DB per year, the JET sizes remain quite modest - especially compared to what Exchange used to hit on JET.

I'm rather unclear how this can be considered (and promoted by Veeam as) a multitenant, SP solution for SPs to provide BaaS without quotas being in place and working. The whole way multitenant works is clearly a workaround process which basically uses multiple O365 org, and multiple repo support to try and emulate multitenancy. About the only compelling reason I can see to use VBO365 and not a SaaS etc offering is that it lets us sell the storage we have already bought. Sure it works, but it's clunky to set up and emulating quotas via one repo per virtual disk per tenant is "suboptimal".

Picking up on
>It is a soft limit, meaning that we will go over the limit to finish the job, but then a new job is not started
It doesn't seem that hard to have the first task in a job to be to check the total size of the JET repo and fail with a error if the repo is larger than the limit stored in the DB?
If we stopped VBO365 doing the scheduling, I could write the whole thing as a PowerShell pre-job-script that only started the job if the repo size is under the limit. That's how simple this seems to be to implement. Did I miss something, that makes it much harder?
Sure, it would still be a soft limit - but I bet for many people that would be enough, given the alternative is to frig multiple disks and force JET to run out of space as a "quota".

Thanks

[aapalacios]

Is possible to set a space limit to a backup repository? example, 500 GB for each organization?

[Vitaliy S.]

That's not possible at the moment, but can you please give us a bit more info on why do you need this and what would be an expected behavior when the quota is reached?

[marco777]

Hi

is there still no way to put a quota on an Microsoft 365 repository?!
Is this planned in an upcoming release?
Thats definitely a mandatory feature for service providers...

Thanks

[Mike Resseler]

You can put a soft quota on an object storage repository. It is soft because it will go above the quota to finish a job. See here as example for S3-compatible: https://helpcenter.veeam.com/docs/vbo36 ... tml?ver=70

[mts13414]

Ran across this post while Googling to work out how to do this. I presumed I was looking in the wrong place, or I have configured something wrong.
I made a complete assumption that this obvious feature would be there. How could it not be?

Genuinely shocked it's not an option. As others have said in this thread, it's kinda mandatory for service providers.
Sure, we're paying for Veeam Licences - but we don't care how many the client is using as long as they're paying our invoices each month.

What we really care about is the user exceeding the quota we provide with those licences.
We would have an alarm to tell us to know when they're approaching their set quota so we can sell them more storage, or negotiate changes to their retention.

Any idea when this will be implemented?

[AlexHeylin]

For another view - we set up each VB365 tenant as a separate sub-tenant in our S3 provider (Wasabi), and just bill the tenant for their S3 usage. The CSV export from the S3 management portal (WACM, as a "reseller") is pretty easy to ingest and run through our billing platform so billing is nearly automated.
We quote customers on a per-unit (mailbox / license, and TB) basis and give an estimate of expected cost based on their current environment. That allows us to just bill on usage as things change.