mwrusnak
Adding the database backup first was done because adding it last could cause backups to hand indefinitely.
In my tests, I haven’t been able to reproduce your issue. The database file is there when the complete backup finishes.
Do you get any error messages on a manual backup?
Did the previous backups contain the database ?
thanks
Paul
Paul,
Thanks for the quick response. I do not get any error messages when running a manual backup, and all of the other files are included in the zip file, except for the database.
Previous backups did include the database file successfully. On the live server, I’m running version 3.1.3 of BackUpWordPress, which still is working correctly.
My backups are very large, at about 500 MB, so it might be the same problem this user was having:
https://wordpress.org/support/topic/complete-backup-does-not-contain-sql-database-file?replies=4
Since the backups are large, it takes a few minutes for them to run, soI could see that the zip file initially contains the .sql file before the regular site files are added. (That was what led me to test removing the -FS option.)
I’m running a CentOS 7 box with no custom packages installed. In a shell, if I type “zip –version”, I have Zip 3.0 by Info-ZIP — I don’t know if there are other zip variants in other distributions, but maybe that is worth checking, in case they handle the -FS option differently.
Thanks for looking into this — let me know if any additional information would help.
It’s strange because I’m able to run a 3GB backup on my test setup without an issue. But I will release an update which will allow to filter the mysqldump options.
Ok, so large files must not affect it then.
The mysqldump portion does seem to be working correctly for me, it’s just that after the .sql file added to the initial zip file, it is then removed when the rest of the files from the site are added — so the “-FS” option of zip is the problem for me.
I tried this on another site on the same test server, and the database was included — I am not sure why!
Back on the large site though, I changed “-rq” in the zip command line to “-r”, so I could see what zip was outputting, and I got this message:
BackUpWordPress detected issues with your last backup.
deleting: database-172-16-1-131-backup.sql
adding: wp-settings.php (deflated 69%)
adding: wp-signup.php (deflated 75%)
adding: wp-cron.php (deflated 56%)
adding: wp-comments-post.php (deflated 68%)
(…)
So zip is actually removing the SQL file on purpose, but I still don’t know why it does it on one site, but not on the other. I even tried removing all of my excludes, as I was excluding some folders from a cache I’m no longer using, but that did not help.
Strange?
Working on a fix. I will remove the ‘-S’ option as it is causing issues for a lot of users
When I comment out line 1007 in /classes/class-backup.php
//$command .= ‘ -FS ‘;
the backup runs successfully and contains the .sql extract.
This was on a shared server on Dreamhost.
On a shared server, 500Megs will likely run out of PHP memory.
Check your error logs (~/logs/domain.com/http/error.php) for anything that says unexpected end of file.
My backups are less than 200 MB.
I will check the error logs though to see what is in them in regards to the issues I am having.
Pretty sure it has to do with the plugin though, and not the fact that I am on a shared Dreamhost server.
For what it’s worth, I’m on a VPS through a different hosting provider — the next version Paul mentioned above will probably fix the issue since he’s changing the command-line options that we tweaked in testing, so that’s good!
I’m still not quite sure why two sites on the same server work differently, since the local ‘zip’ utility seems to be where the trouble lies, though. Maybe some odd bug in zip itself..
I checking the error log on my site and found nothing in there in regards to unexpected end of file.
Anyone still experiencing please Enable Support and open a ticket through Intercom.
Cheers!
Owain
