MySQL: Retry DB dump if dump failed for an account

George Patterson shared this idea 5 months ago
Under Consideration

We have noted that the JetBackup will skip an account if the mysql connection "goes away". Instead it would be better for JetBackup to retry a couple of times.

Jetbackup version: 4.0.16-1 (Beta Tier)

Example entry from the backup log

[20 August 2019 05:33:30 PM +1000] Account "account"

[20 August 2019 05:33:30 PM +1000]

[20 August 2019 05:33:30 PM +1000] Account 80 of 101

[20 August 2019 05:33:30 PM +1000] [ERROR] Skipping Account - MySQL server has gone away

[20 August 2019 05:33:30 PM +1000] Executing onBackupAccountEnd Hooks...

[20 August 2019 05:33:30 PM +1000] onBackupAccountEnd Hooks Done

Comments (3)


Hi George,

The "MySQL server has gone away" issue has been patched with the latest update for 4.0.16.

With that said, our team will review your request for a database dump retry feature and update

here accordingly.

Best Regards,

JetApps Team.


Yes, That seems to be the case. We have had a failing JetBackup for the same account for a few weeks. That seems to have been resolved with 4.0.16-5.

I will be looking forward to the database dump retry feature.

Thanks for the Update.



We have a similar problem in 4.0.16:

[04 September 2019 04:02:16 AM -0400] Databases

[04 September 2019 04:02:16 AM -0400] Grabbing...

[04 September 2019 04:02:16 AM -0400] Dumping Database '*****_wp' (Engine: MySQL)...FAILED

[04 September 2019 04:02:16 AM -0400] [ERROR] mysqldump: Got error: 2002: "Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)" when trying to connect

That was #53 of 100+ accounts and the only one to have an issue. We suspect that MySQL was restarting as part of a cPanel update at that exact moment. A delay/retry seems like a good idea here; clean MariaDB restarts are relatively quick, but a hard crash can take quite some time. I'd be inclined to wait at most 60 seconds before skipping the account's databases and moving on.