O THER SCHEDULERS : ANACRON AND FCRON

In general, cron does not compensate for commands that are missed while the sys-tem is down or for large discontinuities in the flow of time. However, Vixie-cron does make a good-faith effort to do the right thing for jobs that are scheduled on a less-frequently-than-hourly basis when the time changes by less than three hours. It does a good job at handling small adjustments such as those related to daylight sav-ing time in the United States.

Laptops and other machines that are powered on sporadically have a more strained relationship with cron and can benefit from some backup. A nice complement to cron can be found in anacron, which is an interval-based scheduler. If anacron is not included in the default installation, you can install it through your system’s de-fault package management system.

Instead of specifying that a particular command be run at 2:00 a.m. on Monday mornings, in the anacron world you simply ask that it be run every week. Unlike cron,anacron maintains a record of each command’s most recent execution time, so it can simply compare this time, the specified interval, and the current time to determine whether the command needs to be run again.

anacron provides several features that help prevent a newly booted machine from submerging under a wave of simultaneous maintenance tasks. Each task can have its own startup delay, and anacron can serialize the commands it runs so that only one command is active at a time.

Interval scheduling is probably more generally useful than fixed-time scheduling for administrative tasks. Unfortunately, anacron requires its intervals to be expressed in days, and this fact limits anacron’s utility as a first-line scheduling tool.

anacron itself must be run out of cron. Although anacron’s scheduling granularity is days, it makes sense to run anacron more frequently than once a day—if you

Periodic Processes

8.6 Exercises 157

knew cron would be able to consistently run anacron at the same time each day, you probably wouldn’t be using anacron in the first place. Similarly, it makes sense to run anacron at system startup as well.

A more aggressive revamping of cron that includes anacron-like features can be found in fcron; see fcron.free.fr. Unlike anacron,fcron aims explicitly to replace Vixie-cron. It permits a number of sophisticated timing specifications that are not expressible in the cron and anacron configuration languages. Nevertheless, one has to wonder whether the practical value of these features justifies fcron’s added com-plexity and the hassle of using a nonstandard scheduler.

8.6 E

E8.1 A local user on your system has been abusing his crontab privileges by running expensive tasks at regular intervals. After asking him to stop sev-eral times, you are forced to revoke his privileges. List the steps needed to delete his current crontab and make sure he can’t add a new one.

E8.2 Think of three tasks (other than those mentioned in the chapter) that might need to be run periodically. Write crontab entries for each task and specify into which crontab files the entries should go.

E8.3 Choose three entries from your system’s crontab files. Decode each one and describe when it runs, what it does, and why you think the entry is needed. (Requires root access.)

E8.4 Write a script that keeps your startup files (~/.[a-z]*) synchronized among all the machines on which you have an account. Schedule this script to run regularly from cron. (Is it safe to blindly copy every file whose name starts with a dot? Should files being replaced on the destina-tion machines be backed up before they are overwritten?)

E8.5 Using the man pages for the du,sort, and head commands as references, write a script that determines which 10 home directories are the largest on the system. Schedule the script to run every Monday night at 12:00 a.m.

and have it mail its output to you. Hint: you’ll want to use a reverse nu-meric sort. (Requires root access.)

158

9 ^Backups

At most sites, the information stored on computers is worth more than the computers themselves. It is also much harder to replace. Protecting this information is one of the system administrator’s most important (and, unfortunately, most tedious) tasks.

There are hundreds of creative and not-so-creative ways to lose data. Software bugs routinely corrupt data files. Users accidentally delete their life’s work. Hackers and disgruntled employees erase disks. Hardware problems and natural disasters take out entire machine rooms.

If executed correctly, backups allow an administrator to restore a filesystem (or any portion of a filesystem) to the condition it was in at the time of the last backup.

Backups must be done carefully and on a strict schedule. The backup system and backup media must also be tested regularly to verify that they are working correctly.

The integrity of backup media directly affects your company’s bottom line. Senior managementneeds to understand what the backups are actually supposed to do, as opposed to what they want the backups to do. It may be okay to lose a day’s work at a university computer science department, but it probably isn’t okay at a commodity trading firm.

We begin this chapter with some general backup philosophy, followed by a discussion of the most commonly used backup devices and media (their strengths, weaknesses, and costs). Next, we discuss Linux backup and archiving commands and suggest which commands are best for which situations. We then talk about how to design a backup scheme and review the mechanics of the populardump and restore utilities.

Backups