On 03/04/2012 07:25 PM, Tim Dunphy wrote: > hello list, > > I am attempting to backup a centos 5.4 (x86_64) server running mysql > with a cron job. Here's how the cron job looks: > > [root at cloud:/home/bluethundr/backupdb] #crontab -l > * 3 * * * /usr/bin/mysqldump jfwiki> > /home/bluethundr/backupdb/wiki-$(date +%Y%m%d).sql > > However if I run the command from the command line it seems to work fine. > > > If I grep syslog for cron this is what I've found: > > Mar 4 22:12:13 domU-12-31-38-07-49-CC syslog-ng[1174]: Log > statistics; processed='center(queued)=16141', > processed='center(received)=16141', processed='destination(d_boot)=0', > processed='destination(d_auth)=3', > processed='destination(d_cron)=131', > processed='destination(d_mlal)=0', processed='destination(d_kern)=0', > processed='destination(d_mesg)=200', > processed='destination(d_cons)=0', processed='destination(d_spol)=0', > processed='destination(d_mail)=15807', processed='source(s_sys)=16141' > > I've tried bouncing the crond service but even if I set the cron job > to run every minute the backups don't run. > > I was hoping someone out there might have some advice n how to solve > this problem. > > thanks I'll start by suggesting that you really don't want to backup every minute - as soon as the data size grows bigger than what can be dumped in a minute, you're going to run into some serious problems. We backup all our databases hourly to avoid these types of problems, and a typical backup time is about 15-20 minutes. I suggest taking your command and putting it into its own shell script. Call every command explicitly - full path as returned by which, eg: /usr/bin/mysqldump instead of just mysqldump, /bin/date instead of date, since cron runs with different environment variables. The crontab entry should also reference the full path to the script EG: /usr/local/bin/mysql_backup.sh instead of mysql_backup.sh - this also provides some security benefits since if you have the permissions straight, you won't inadvertently run the wrong script (perhaps containing an exploit) due to an unexpected problem with either the environment or inadvertent write permissions on the wrong directory. Also, don't run this as root. Not that you can't, it just causes the script to run with more privileges than are strictly necessary. Add a user "mysqldump" or something and run the script in that user's crontab. I'd recommend that you don't give this user a password so it can't be inadvertently used against you. Lastly, have your backup script produce some output at the end, EG: echo "Script complete" and then check the email of the user running the cron job. My $0.02, good luck!