On the Many Ways for cron to Fail

Ever since we used database on the server, the problem of backup manifested itself. We no longer have an exact local copy of what is on the server. Thus we decided to use cron to do periodic backup only to find many ways for cron to fail. Everyday we check if a backup file is created or not. If not we create a manual backup. Up to this day, we have not received an automatic copy. lol.

• cron is not running at all. Yep, to conserve resources, almost nothing is configured to run by default on our (old) server. Don't laugh at us.
• You missed a friggn newline at the very end of crontab. This shows the advantage of using crontab -e to create cron job for a user. It will tell you that you have missed a newline.
• You need to escape % in crontab. For example, the method in the this link does not work. We copy here the line:

15 2 * * * root mysqldump -u root -pPASSWORD --all-databases | gzip > /mnt/disk2/database_`data '+%m-%d-%Y'`.sql.gz

Note that the word data in the crontab entry should be date. We should vote this link down. You will get an error: EOF in backquote substitution. Also it is bad practice to have the password visible on the command line. One can use --defaults-extra-file to supply a conf file which has the content

[client]
password=PASSWORD

[Edit: We are starting to use $(...) for command substitution. In addition, we have written a bash script to do the backup and let cron run it everyday. This is much more flexible and much less error-prone.]