Backup creation allows accounts to exceed disk quota
Answered
Hello,
I’ve noticed a situation in cPanel that I believe should not be allowed, or at least should be handled differently.
Here’s the scenario:
-
A user has a 100 GB quota.
-
They have already used about 98 GB.
-
From within their account, they generate a backup.
What happens is that cPanel allows the backup to be created, even though it causes the account usage to go well over the assigned quota (e.g., 196 GB). The backup process does not fail once the 100% quota is reached — it continues writing to disk and completes successfully. The account continues to function: the backup can be downloaded or transferred without restriction.
In practice, this means:
-
The system does not block backup creation when the process itself will push the account over 100% usage.
-
Quota enforcement is bypassed: normally, when an account exceeds its limit, emails bounce, file creation is blocked, and errors appear. But in this case, the backup process is still allowed to consume disk space beyond the quota.
My questions are:
-
Why is backup creation allowed to exceed the quota limit and continue writing even past 100%?
-
Shouldn’t cPanel either:
-
Require enough free space so the backup can fit without going over quota, or
-
Block/terminate the backup once the account reaches 100% usage?
-
-
How can this behavior be prevented?
Disabling the backup feature manually in the user’s account is not a valid solution, since this only removes functionality for the user instead of enforcing quotas consistently.
From an admin’s perspective, this looks like an inconsistency: quotas strictly enforce limits for normal usage, but backups are treated differently and effectively bypass those limits.
Thanks in advance for clarifying if this is expected behavior or a bug, and whether there’s a configuration/workaround to prevent this situation.
-
For my opinion, cPanel should allow backup creation, even when it results account being over quota.
BUT I think cPanel should warn the user that after backup creation the account is over quota, and the backup should be copied elsewhere and removed.0 -
I did confirm this behavior happens on both a standard cPanel installation and within CloudLinux with CageFS enabled. I'm reaching out to the team now to see how they'd like to handle this, as this has been the standard behavior for some time, even though I don't personally think that's how it should behave.
I'll let you know what I find out!
0 -
quietFinn I understand your point, but I respectfully disagree. In my experience, allowing backups to bypass quotas — even with just a warning — leads to major issues in real-world environments.
For example, users close to their quota often generate backups “just in case” or to migrate, and then leave those backups sitting in their account. Very quickly, they exceed their quota and the account becomes unusable (mail bounces, files can’t be created, etc.). As admins we constantly have to step in and manually disable backups for these accounts, and unfortunately many customers see this as us trying to “force” them to upgrade, which isn’t the case at all.
Disk space is often a limited and valuable resource, especially on smaller servers without overselling. Quotas should apply consistently, and backups should behave the same way as normal usage: once you hit the limit, you can’t keep writing data. Otherwise, the quota enforcement loses its meaning.
cPRex Thanks for confirming this, and I really appreciate you taking the time to escalate it.From the admin perspective, this behavior has always been a pain point. Even though it’s been the “standard” for years, it creates constant over-quota problems with users who generate backups while near their limit. Many times we end up disabling the feature manually for those accounts, which often causes misunderstandings with customers who think we’re restricting them unfairly.
It would be much more consistent if backups were treated like any other disk usage: either require enough free space before starting, or stop once the quota is reached. Otherwise, the quota system loses credibility because it enforces limits everywhere except backups.
Looking forward to hearing what the team decides on this — I think a change here would be very beneficial.
0 -
In my ideal universe, there is a disk space check that runs either right when the user starts the backup that tells them is they are using more than 50% of their quota, and the backup can't run, or something along those lines.
With the current behavior it could lead to a serious issue for the server - if the account is 100M, big deal - they make a compressed backup and end up with 150M or maybe 175M of usage. But if that account is 200G, that could quickly fill a partition.
I was hoping to hear more today but I didn't hear back from the team, so I should have something tomorrow.
1 -
I spoke with the team and we all determined this is an issue with the product. I've created case CPANEL-47704 so the disk space is checked before the backup process is executed by the end user. If I hear any updates on that I'll be sure to post!
0 -
Thank you for confirming this and for opening the case. I’ll keep an eye out for updates so I know when this has been implemented. Much appreciated!
1 -
You're very welcome!
0 -
Any update on this ? How can i track the case?
0 -
Yes! I do see it's been tagged for the 136 branch, so if it's going to get fixed it'll happen by then. Currently the team is evaluating how "expensive" it is to run that disk check as part of the backup interface.
0 -
Update - it seems we have a fix for this and it will be included in all versions of 136 once that is released!
0 -
Update - I've confirmed a fix for this will be in place in version 136.
0
Please sign in to leave a comment.
Comments
11 comments