7

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/mysqlbackup.sh

#!/bin/bash
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/mysqlbackup.sh

..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

sadmicrowave
  • 1,068

4 Answers4

7

Few points to make:

  • Why are you using timestrings in /etc/cron.weekly/ scripts at all? You're only supposed to 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.

Pavel Chuchuva
  • 105
  • 4
Oli
  • 293,335
  • 3
    sudo chmod +x /etc/cron.weekly/mysqlbackup.sh 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 05 '11 at 12:32
  • @geirha That is a very important comment! Is that documented anywhere? – lmat - Reinstate Monica Aug 22 '13 at 14:30
  • 2
    @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
2

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: http://en.wikipedia.org/wiki/Cron

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

ImaginaryRobots
  • 9,136
  • 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 05 '11 at 13:55
1

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

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

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/mysqlbackup.sh

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.

sadmicrowave
  • 1,068
0

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

/usr/local/mysqlbackup.sh &>/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.

bitwelder
  • 376