I second this.
The plugin creates an SQL dump (ca. 35 MB) and leaves it in the backup directory. I suppose it also tries to send it via email, however, due to the file size this mail is never received.
So I noticed several problems:
1) Old dumps are not deleted (sometimes). There are files older than 2010-12-21, so this did happen before 2.2.3, too.
2) Backups are not mailed any more. My last mailed backup was on 2010-11-14. I scheduled a weekly backup.
3) SQL dumps are not compressed any more. Probably since 2.2.3. Maybe this is due to the large size of my dumps (just found http://wordpress.org/support/topic/wp-db-backup-creates-file-but-no-email-is-sent?replies=13 and will check).
PS: Some googling led me to this gem, where they unpack a gzipp’d file in chunks. This should also work the other way round.
I would offer writing a patch for the plugin. Is there only one part where you compress (below “Try to compress to gzip, if available”)?
It was compressing in chunks before, but then the gzipped file would report an incorrect uncompressed file size, which would cause the unzipping to fail on a couple of common zip clients.
So the trick is not compressing in chunks, but doing so in a way that reports the correct uncompressed file size.
My number one support question used to be from people who would use one of these gzip clients, have the extraction fail, and then think that their backup was lost a crucial moment.
What about giving the user an option to select the compression method? Or try to detect when the one-step method will probably fail (e.g. dumpsize > 0.5 memory_limit, maybe?).
Do you have links to bug reports for the wrong file size? I’d like to read a bit into it.
Could this be related to using the real directory ‘backup-77784’?
On most systems, /tmp is practically unlimited and could be used to store temporary files, which will then be compressed and/or emailed.
it’s confirmed, it’s 2.2.3 version issue.. I revert back to 2.2.2 and voila, the backup normally get compressed again..
I’ve had a similar issue which I resolved by adding this line to wp-db-backup.php
This increases the memory limit for PHP provided the server allows this command and the gzipping then has more resources to play with before running out!
I noticed over 800MB of .sql files piling up for one of our clients. We were experiencing the the same issue.
I added: ini_set(‘memory_limit’, ‘128M’);
To the top of wp-db-backup.php and now the file is zipped and cleaned up properly.
The DB doesn’t get compressed, only the backup file. It’s part of what the plugin does by default. No need to do anything for it.
Since my last interaction, by the way, I’ve had a problem that was traced back to /tmp issues, so talk to your hosting provide’s tech support if nothing else helps. Sometimes, a quick server restart kills runnaway processes and frees up /tmp for useful work like … backups.
Using 2.2.4-beta, backup files are compressed again using external gzip. Thanks, Austin.
However, now I have the problem that full DB backups are not mailed to me, probably because the compressed file size is > 5MB. Is there a way to raise the limit of sendmail from PHP?
PS: emailing smaller backups (w/o additional tables) works. So it seems not to be an email problem per se.
I was having the same problem with the download not popping up, backups not being e-mailed to me (I don’t usually do this, but tried it when downloading the backup to my computer didn’t work), and backups not being deleted from the server. As for f00f, upgrading to 2.2.4-beta resolved the issue in my case.
(Oddly, the issue was only happening on one of my two WP sites; version 2.2.3 continues to work properly on the other — possibly because it is a smaller site with fewer active plugins? I use the same host for both, and the site configurations beyond the plugins are identical.)
- The topic ‘[Plugin: WP-DB-Backup] the backup file is not compressed’ is closed to new replies.