Database Backups Not Working.

[Timothy]

Hi guys,

I seem to be having a issue with database backups. Attempting to do a manual backup leads to a 26 byte gzip archive to download. The sql file is empty. This is happening on version 3.0.6.

Anybody have any idea why this might be happening?

[Paul]

Make sure you have the mysqldump binary on your server, mysqldump is used to generate the backup.

[Timothy]

It is installed and works when I use it manually.

[Paul]

It is installed and works when I use it manually.

 

What is its location? Also, your temp directory is set and writable, correct?

[Timothy]

mysqldump: /usr/local/bin/mysqldump

The temp folder is setup correctly and writable according to settings/system/general/basic/.

[Paul]

Does your server allow the use of the exec() command?

 

Does your server know where mysqldump is, or do you need to run it with the full path, ie /usr/local/bin/mysqldump? You could edit app/models/backup.php to test that by putting in the full path in the exec command before mysqldump.

[Cody]

Does your server allow the use of the exec() command?

 

Does your server know where mysqldump is, or do you need to run it with the full path, ie /usr/local/bin/mysqldump? You could edit app/models/backup.php to test that by putting in the full path in the exec command before mysqldump.

 

BTW, CORE-136 is scheduled for 3.2.0 and will allow users to specify the path to the mysqldump executable.

[Timothy]

Does your server allow the use of the exec() command?

 

Does your server know where mysqldump is, or do you need to run it with the full path, ie /usr/local/bin/mysqldump? You could edit app/models/backup.php to test that by putting in the full path in the exec command before mysqldump.

 

The server does allow the use of exec. In fact it has no disabled functions. The user Blesta is running under does have /usr/local/bin in path and can execute mysqldump binary.

 

Changing the backup.php to hard code the path to mysqldump gets me a step further. Now I get 373 byte backup. Basically the first 10 lines of sql and then it cuts off.

[Timothy]

It looks like there are two problems. 

 

Mysqldump was not working with the Blesta database user due to not having lock tables permissions. My previous manual test used a admin user that did have those privileges. Updating the privileges of the Blesta database user to to be able to lock tables fixes the dump with a hard coded mysqldump path.

 

The question I have now is why does it require a hard coded path when mysqldump is in the path environment and works correctly when run as the Blesta server user. Also, are there any other side affects of not have lock tables permissions with Blesta? Perhaps a check when Blesta is installed for the lock tables permission would be useful.

 

In any case, with a hard coded path the issue is solved for the moment.

[Cody]

Sounds to me like the Blesta cron user doesn't have mysqldump set in their environment path variable.

 

As for locks, they're not required at all. The only time it's used is for mysqldump execution, though that's only because your default database setting is to lock tables on a dump. Perhaps a feature request is in order to allow users to choose whether or not to lock on database dump (i.e. mysqldump --single-transaction --quick)?

[Timothy]

Perhaps as an addition to CORE-136 you could allow people a place to to add advanced parameters that are then passed directly to mysqldump. I think this is probably a corner case scenario but it might be useful enough considering you already have CORE-136 open.

 

This thread can be marked as solved. It looks like both the issues are server specific and not Blesta at all. Sorry for the noise.

[Trev]

I also had a problem with the environment path but it resulted in the Apache CPU usage shooting up to 100%. I didn't notice anything until I started receiving health monitor alerts from the server. In the end I had to kill the cpu process for the cron job.

Perhaps there needs to be a test of some sorts to prevent this occuring?