Aborted backup is incorporated into next backup

Hi @webaware
So you have setup both jobs using WP Cron?
In this case, I think WP Cron was run incorrectly, could you set up the job to start with a link and using your real server cron?
Hope that help!

G’day duongcuong96,

Yes, have done something about more reliable cron triggering. That should hopefully keep things on track.

However, the issue is that because there was a failed complete backup, the file for that backup were incorporated into the following db-only backup. A failed backup should clean up its files, not leave them for the next backup. In this instance, it meant that what was intended to be a quick db-only backup became a lengthy complete backup in the middle of the day.

This could be avoided if either a failed backup cleaned up its files when detected, or if each new backup cleaned the temporary file area before commencing. The former approach would not impact general performance of the backups.

cheers,
Ross

@webaware
Sorry for my late reply,
Normally, if the job is aborted or failed, BWP will detect and clean all files in its temp folder.
I was trying to reproduce your problem but I couldn’t.
So could you please tell me more detail information about your case to help reproduce the issue?
Thanks

hi @webaware
Could you please help me on how to reproduce this issue?
Thanks!

Sorry for the delay, things got on top of me.

The server is a shared server (host: Conetix, in Australia) but very lightly loaded at the time of the aborted backup. I can dm (Slack) or email you specifics if you need. Here’s a summary:

* WordPress 4.9.5, single site
* no debug mode / log
* Apache server
* MySQL 5.5
* PHP 7.0 with 256MB and:
* Core, date, libxml, openssl, pcre, zlib, bz2, calendar, ctype, hash, filter, ftp, gettext, gmp, SPL, iconv, Reflection, session, standard, SimpleXML, sockets, mbstring, tokenizer, xml, cgi-fcgi, mysqlnd, bcmath, curl, dba, dom, enchant, fileinfo, gd, imagick, imap, intl, json, ldap, exif, mcrypt, mysqli, odbc, PDO, pdo_mysql, PDO_ODBC, pdo_pgsql, pdo_sqlite, pgsql, Phar, posix, pspell, redis, soap, sqlite3, sysvmsg, sysvsem, sysvshm, tidy, xmlreader, xmlrpc, xmlwriter, xsl, zip, ionCube Loader, Zend OPcache

The aborted backup was a zip of the files with standard exceptions + excluding wp-includes, wp-admin; full db; plugins list. The final zip file is 1.14GB. It’s scheduled to run at 3:15am local time according to the website, or 17:45UTC. That night, it was aborted after an hour of inactivity. The schedule is started with wp-cron.

The next day, a db-only backup ran as scheduled at 2:05pm local time, or 5:35UTC. It did its usual database dump, but collected all of the files from the previous aborted backup to create a .tar.bz2 of 1.14GB instead of the usual 3MB.

I’ve since added something to kick along wp-cron periodically, to avoid a repeat of this problem. It hasn’t occurred again.

cheers,
Ross