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@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!
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
