The House is on Fire!

The House Is On Fire!
Crisis Management in Linux

Yesterday we added a script to your collection that creates a backup CD from crucial directories on your Linux system. Looking closely at the script, you should be able to see where modifications can be made to better suit your particular machine and backup needs. Backups can be lifesavers in an emergency. But they can also be a pain in the butt if you have to remember to create them on a regular basis. That’s what computers are supposed to be for, right? Right. That’s why today, we’re going to add the CD backup script to cron, allowing it to run regularly without your lifting a finger.

First, let’s roll back the Penguin Shell clock a month or so and review the purpose of cron. cron is a daemon intended to perform regular and routine system tasks. The cron daemon (crond) fires off at boot time, checking the crontab file regularly to see if there are routine tasks in need of completion. Many of these tasks are defined by a system administrator using the cron -e command, writing a schedule directly to the crontab file. The tasks can be general-purpose items or items that are unique to the system they’re to be performed on. If crond finds a scheduled task in the crontab, it calls on the appropriate system resources to complete the task, then falls back to sleep for another minute. The resources upon which it calls can be built-in commands or shell scripts.

Now, let’s add this script to the /etc/crontab file so that it will run on a schedule without user intervention. On nearly any Linux system, you can add the appropriate scheduling line to crontab directly without problem. If you’re using a RedHat distribution, you may choose to place this script in the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, or /etc/cron.monthly directories. The RedHat crontab executes all scripts in these directories as scheduled, though it will still execute tasks directly from crontab. Some find it easier to organize and maintain your cron tasks in this manner. I tend to add cron entries directly to crontab for the sake of centralization. The latter is the method you’ll find below.

Let’s set this script to run every week at 2:00 am Monday. Open a console window, log in as root, and execute the following command:

    [root@server tony]$ cron -e

This will open your crontab in edit mode. You’ll add a line to the bottom of the existing crontab:

    0  2  *  *  mon root /home/tony/bin/CDBackup.sh

crontab is, in essence, a table with fields. Each field has a value. Those fields, in order, are:

• Minute
• Hour
• Day of month
• Month
• Day of week
• Command

In our CDBackup example, the CDBackup.sh script will now run as root at 0200 every Monday. I’ve chosen to run as root because cdrecord requires superuser priveleges to access the CD-R drive.

One more quick item. Be sure you’ve given your CDBackup.sh script executable permissions. As the normal user, enter the following command:

    [tony@server tony]$ chmod u+x ~/bin/CDRecord.sh

This command [ch]anges the [mod]e of the file, giving the [u]ser e[x]ecutable permissions.

Tomorrow, we’ll talk about how to use fsck to check and fix damaged files and filesystems.