Disk quota exceeded error when there is a lot of space available

disk-“space” is a limitation on a disk (file-system).

Disk-“quota” is an artificial limitation that CAN be imposed on a user (account), that limits how much space they are allowed to use. Preventing that account from eating up all the space on a file-system.

Hence, your disk(s) or filesystem(s) can show as having lots of free space, but still the user or account gets blocked by it’s quota, if one is imposed.

Since all your sites are probably running under the same account, they will all see any quota problem, as suddenly no more space can be allocated.

You probably have an accumulation of old backup files that eventually made your account run over it’s quota, if you have one. Check your account status, or from a Linux prompt use the “quota” command.

This issue is not related to the backup plugin other that it happens to be attempting to write a larger zip-file, and the issue must be fixed in your hosting account, as quota limits EVERYTHING you do. Everything that tries to write on the disk.
Causes WP or plugin updates to fail, logging to fail, backups to fail, …, …

… I will investigate, but what make me wonder is the messages after the error in the log…

[23-Mar-2017 01:00:30] Backup archive created.
[23-Mar-2017 01:00:30] Archive size is 147,11 MB.
[23-Mar-2017 01:00:30] 9001 Files with 223,35 MB in Archive.
[23-Mar-2017 01:00:31] 1. Try to send backup file to Dropbox …
[23-Mar-2017 01:00:32] Authenticated with Dropbox of user: Drauth.org Web Agency
[23-Mar-2017 01:00:32] Uploading to Dropbox …
[23-Mar-2017 01:02:42] Backup transferred to https://content.dropboxapi.com/1/files/sandbox/Le-Dimore-del-Quartetto/Dimore_2017-03-23.zip
[23-Mar-2017 01:02:43] One file deleted from Dropbox
[23-Mar-2017 01:02:43] One old log deleted

Where it seems that the backup has been done and sent. So, or there is a Disk quota issue or the zipping succeeded… Which one should I trust?

Thanks
Simone

I would always tend to preliminarily “trust” anything that reports an error. And attempt to fix based on that. ??

However, I do see a failure here in the Backup-plugin’s error checking process/handling, that personally I would fix QUICKLY if I was the developer.

The process.. Your local issue to fix:

The Backup ZIP is first created locally on your disk.. That’s where YOUR local Quota issue is met. You need to check your local hosting limitations against your userid’s/account’s overall disk-storage usage. Then either get allowance for a higher quota (or unlimited), or remove some of the accumulated stuff to get down under the quota. Clean your space.

Notice, that a userid’s quota counts EVERYTHING.. Which means that you can have automated backups working fine for years, and then suddenly because of uploaded stuff over time (such as image galleries and other wordpress files) you blow into the Quota limit, and backup’s WILL start failing. Even though you “backup to DropBox”, that does not mean that the initial backup processing writes directly to the cloud. The backup file is first created locally. Then afterwards saved in the cloud. So, if you cannot create a full-size local backup file to be uploaded, you are toast.

The process.. The plugin’s issue:

Backups need to be of HIGHEST TRUST and INTEGRITY. Main requirement for any backup software. If you cannot trust the content in a backup to be correct and restorable, then the result cannot even be called a backup. Backup software that cannot be trusted is worthless. That includes producing the correct errors and maintaining integrity when something out of the plugin’s control happens. Such as your Quota issue, which the backup plugin has no control over.

So in this case, The backup plugin passes on the ZIP software’s Quota error message (from inc/class-create-archive.php), code sleeps for 1 second, and then according to your log simply proceeds with the next steps of the “save a backup” process after the zip creation apparently actually failed half-way through. Which in your configuration includes copying the actually only half-made and BAD temporary ZIP archive to DropBox. As if it was a good backup file.

But a ZIP file creation that stopped in the middle because of space or quota issues is NOT A BACKUP file. It is practically nothing but a junk file. A partially made archive, that is missing unknown parts of the intended backup is worse than worthless and almost worse than nothing. Worse because the log indicating success and the (failed) archive files uploaded to DropBox gives the site admin a false sense of security..

“See all the nice backup files I have in DropBox..” Each file in reality worthless, because it is a half-completed archive that does not actually restore a site the way it should. (Backup Parts missing)

So.. in my opinion, you need to fix your Quota issue. That will allow your backup’s to be completed correctly without this quota error.

The plugin owner (Inpsyde) subsequently need to fix the plugin’s error checking and process to ensure that when archive creation fails because of space or quota issues, ALL further processing stops, and failure is reported to the Admin. That includes making sure that corrupted (half completed) archives are not saved away or uploaded to the cloud as if they were actually backups. Because they are not. A corrupted backup is not a backup.

Regarding the issue itself, the problems happens on the user machine, and this is not something we can really fix, as it seems not a plugin issue.

If the archive is created, we upload it anyway, yes.

The plugin owner (Inpsyde) subsequently need to fix the plugin’s error checking and process to ensure that when archive creation fails because of space or quota issues, ALL further processing stops, and failure is reported to the Admin.

A corrupted backup is not a backup, yes, but it might be useful sometimes anyway.

Assuming a backup archive contains database + uploads folder, and assuming it got corrupted you don’t surely want to restore your website form there. So it’s no a backup. But for example, if the images can be taken from the archive, and it contains images that are only there, the user will be gratuful to have that such corrupted archive. When someone needs a backup, that’s quite surely an emergency case, and in emergency cases something is better than nothing.

Of course, the admin must be notified if error happens and that happen already.

Maybe we could add an option to skip uploading errored archives, seems reasonable, but doing it by default does not sound the good thing to do here.

It is definitely true, that even a partial backup can be useful at times.
Partial or even partly corrupted backups have saved my butt in extracting some files a number of times.
So leaving the file behind, even if only partial, is not a bad idea at all.. But maybe it should be named differently. adding a “partial”, or “failed” keyword into its name.

On admin’s noticing that a backup failed, that requires a clear idea of the impending doom from the log. ??

The log the OP attached above (see below) is totally devoid of any failure information.
Reading the log, one would believe that everything went smoothly, and that there is a valid backup file. No issue to go fix.

In my opinion, the log should include the failure information, and even probably the Zip-status message.. Not sure whether this OP has logs emailed to them or what the email subject would be.. As the OP indicated above

Where it seems that the backup has been done and sent. So, or there is a Disk quota issue or the zipping succeeded… Which one should I trust?

But IF my emailed backup logs contained nothing but the below, there would be little to indicate that the uploaded backup was not OK for anything but potential catastrophic file-extraction and partial use.

[23-Mar-2017 01:00:30] Backup archive created.
[23-Mar-2017 01:00:30] Archive size is 147,11 MB.
[23-Mar-2017 01:00:30] 9001 Files with 223,35 MB in Archive.
[23-Mar-2017 01:00:31] 1. Try to send backup file to Dropbox …
[23-Mar-2017 01:00:32] Authenticated with Dropbox of user: Drauth.org Web Agency
[23-Mar-2017 01:00:32] Uploading to Dropbox …
[23-Mar-2017 01:02:42] Backup transferred to https://content.dropboxapi.com/1/files/sandbox/Le-Dimore-del-Quartetto/Dimore_2017-03-23.zip
[23-Mar-2017 01:02:43] One file deleted from Dropbox
[23-Mar-2017 01:02:43] One old log deleted

@crudhunter, thanks a lot for your feedback on this! Is there any way I could contact you directly? That would be great, just contact me on a.frison at inpsyde.com

@seville76, I sent you an email.

Hi @drauth,

Are you still having this issue? If so, feel free to let us know. Otherwise, please mark this topic as resolved.

Solved, it was a matter of lack of space during the zip creation (temporary files). Increasing space vanishes the issue…

Thanks @drauth. Glad this could be resolved for you.