Support

Technically, at this point the backup is done. Adding error handling will do what? If the MySQL server is dead I can't mark the backup as failed, can I? Moreover, the post-processing steps run after the call to set_or_update_statistics(). Let's compare what happens now and what would happen with the - intentionally left out - error handling:

NOW: The main backup process finishes. The backup is valid. MySQL is dead. I don't care. Post-processing runs and the archive is stored to, say, Amazon S3. User is happy, backup is safe.

WITH ERROR HANDLING: The main backup process finishes. The backup is valid. MySQL is dead. I pick it up and call it a failed backup. I delete the backup archive. MySQL still shows it as running ( the connection is dead, remember? ). Post-processing never runs. User visits the back-end and sees a failed backup (pending backups are force-failed when visiting the Control Panel) and no file in S3. User gets angry and claims that the advertised cloud backup feature doesn't work. And I do, what? Punch his host in the face because he kills the MySQL connection within a second or so? Well, I probably should, but...

Both of the solutions are suboptimal. What I am intending to do is run the table update on a new step, so that there is a fresh db connection and the query doesn't fail ;)

Dead MySQL = MySQL timeout. We're talking about the same thing.

If a backup is set to "run" when the Control Panel is launched, the status is set to "failed" and all files are removed. I checked it, it's working here. Same goes when rerunning the backup file. The same cleanup method is called both times, removing old and - presumably failed - archives.

Let me rephrase it in the exact terms I meant:

If the MySQL connection is dead (due to a client or server timeout, the mysqld process experiencing an error, the network, shared memory or connection pipe being suspended/broken/terminated/otherwise blocked or hampered or not properly functional, or any other event which might prevent the PHP thread or process from accessing the MySQL server resources) then... (rest of my message).

I thought that adding this long list of things which would go wrong is as nonsensical as the worst form of legalese, therefore I just used the term "dead MySQL" which meant to be perceived in this context.

I take your point about the connection timing out. I will close and reopen the db connection when running in CRON mode to ensure that this error doesn't happen with long-running backup jobs.

I will post the fixed release later today. I am now testing this (only for the native CRON mode): as soon as the database backup is over, the database connection is closed and the database object freed. Once the file backup ends and the engine hits the finalization stage, the database object will be automatically spawned (and reconnected to the MySQL server) just before the backup stats record is updated. This should be enough to avoid the connection timeout, as the bulk of the database-idle backup process (file packing) will be performed without an active MySQL connection.