Sign up ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

I want to make a backup of my /var/lib/mysql and /var/www folders and save them as tar.gz files to my mounted network file server (uslons001).

Here is my bash file located in: /bin/backups/

mkdir /home/lv_admin/uslons001/`date +%d%m%y`
cd /home/lv_admin/uslons001/`date +%d%m%y`
tar -czf mysql.tar.gz /var/lib/mysql
tar -czf www.tar.gz /var/www

Which works PERFECTLY fine when I execute it in a cmd shell but when I setup the cron job it never runs, so I'm not setting the cron job up properly. My cron job looks like this.

   36 10 * * 5 /bin/backups/

..there is also nothing in the /var/log/cron.log file, so no errors are being logged. (even after enabling cron logging in the /etc/syslog.conf file

share|improve this question

4 Answers 4

The day of the week is a numeric field, so it's failing while trying to parse 'fri'. Change that to 5 (sunday is 0). edit: I see the OP was updated to fix this and there are still issues, but they're addressed in other answers.

The cron format is well documented online, so I usually end up checking the docs before writing a new cron job:

Additionally, make sure you're using crontab -e (or similar) to edit your cron file, which will make sure it gets re-parsed.

share|improve this answer
thanks for your input, please check my OP for an update – sadmicrowave Mar 4 '11 at 14:49
fri and 5 are both valid. Not all implementations of cron allow you to use an abbreviation instead of a number for the weekday, but the cron in Ubuntu does. See man 5 contab – geirha Mar 5 '11 at 13:55

Few points to make:

  • Why are you using timestrings in /etc/cron.weekly/ scripts at all? You're only supposed tgeirha o put executable scripts in there. You don't need to crontab them or anything else. That will just duplicate their work. Look at /etc/cron.daily/apt for an example of what I'm talking about. It's just a plain script.

  • Per geirha's comment, the file can't have an extension. Odd, I know, so rename it:

    sudo mv /etc/cron.weekly/mysqlbackup{.sh,}
  • You need to run sudo chmod +x /etc/cron.weekly/mysqlbackup to make it executable. You can then test it by running it, using that path.

  • If you leave it in /etc/cron.weekly/, the script is going to run as root. None of your ~/ links are going to work. Use full paths. I'd suggest that after you do the mkdir you cd into it and that will reduce the huge paths in subsequent commands. If you need the generated files to be owned by your user, make your script chown them to your user when it's done backing up.

    I don't see any reason for any of this to be root driven. You could plonk the script in your home directory and just use the standard crontab -e to add your rule and have it run. It still needs to be executable and I'd still recommend you use full paths, but it keeps the permissions slightly easier.

share|improve this answer
sudo chmod +x /etc/cron.weekly/ would still not make the script run weekly. Cron ignores files with extensions in those directories. And in general, scripts shouldn't have extensions. – geirha Mar 5 '11 at 12:32
@geirha That is a very important comment! Is that documented anywhere? – Limited Atonement Aug 22 '13 at 14:30
@LimitedAtonement, If you look at the default /etc/crontab, run-parts is used to run the jobs in /etc/cron.{daily,weekly,monthly} if anacron is "not installed". run-parts(8) in turn explains what characters are allowed in the filenames. I believe the main reasoning behind it is to be able to easily disable a job by simply renaming jobname to jobname.disabled or similar. – geirha Aug 22 '13 at 14:53
up vote 1 down vote accepted

I changed the location of the bash file to /usr/local/ After doing so I did the following commands on the file:

cd /usr/local/
sudo chown [username]
sudo chmod -rwx
sudo chmod go=

then I stopped using ~$ crontab -e as the command to edit the cron job and started using sudo nano /etc/crontab where I made a new job line with the following:

00 20    * * 5  root  /usr/local/

I started using this file instead because it enabled me to tell it which user should execute it. After these changes the cron job works.

share|improve this answer

You can try to redirect the errors from your cron line to a file, like:

/usr/local/ &>/var/log/mysqlcron.log

That should catch both stdout and stderr and report if there is any syntax error, etc.

Note: if you are doing backup of a live database, you should use the specific utilities for the backup, like mysqldump, rather than using a generic tar command. Reason is that if files inside /var/lib/mysql/ change while the tar is in execution you may end up with a inconsistent image of the database.

share|improve this answer
cron runs the job with sh unless you specifically tell it otherwise, and &> is not sh-syntax. >file 2>&1 will work with both sh and bash. – geirha Mar 5 '11 at 15:01
True, good point. – bitwelder Mar 16 '11 at 17:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.