Scheduling Tasks with crontab: Automatic Backups and Scripts

Plenty of server chores repeat every day: backups, log rotation, periodic data pulls. None of them should depend on you remembering to run a command. That's exactly what Linux's cron is for: you specify a time and a command, and it runs automatically.

What crontab Is

cron is a background service that runs jobs on a schedule; crontab is the list of those jobs. Every user has their own list, where each line is one job: five fields for when, followed by the command for what to run.

Editing and Viewing

crontab -e    # edit the current user's jobs (first run asks for an editor; nano is easiest)
crontab -l    # list existing jobs
crontab -r    # delete all jobs (use with care)

Once you save and exit, cron picks up the change immediately, no restart needed.

The Five Time Fields

Each job starts with five fields in a fixed order:

# ┌── minute (0-59)
# │ ┌── hour (0-23)
# │ │ ┌── day of month (1-31)
# │ │ │ ┌── month (1-12)
# │ │ │ │ ┌── day of week (0-7, both 0 and 7 mean Sunday)
# │ │ │ │ │
#   *   *   *   *   *   command to run

| Field | Meaning | Range | |---|---|---| | minute | which minute | 0-59 | | hour | which hour (24-hour clock) | 0-23 | | day | day of the month | 1-31 | | month | which month | 1-12 | | weekday | day of the week | 0-7 |

Handy symbols: means "every"; /10 means "every 10th"; 1,15 means "the 1st and 15th"; 1-5 means "1 through 5".

Practical Examples

# Back up a database every day at 3 AM, sending errors to a log file
0 3 * * * /usr/bin/mysqldump -u root -pYOURPASS mydb > /home/backup/mydb.sql 2>> /home/backup/cron.log

# Run a health-check script every 10 minutes
*/10 * * * * /home/user/scripts/healthcheck.sh

# Clean out a temp directory every Sunday at 2:30 AM
30 2 * * 0 rm -rf /tmp/cache/*

# Archive logs at midnight on the 1st of each month
0 0 1 * * /home/user/scripts/archive.sh

> file overwrites, >> file appends, and 2>> captures error messages too, so you have something to read when a job misbehaves.

Common Pitfalls

• Use absolute paths. cron's environment differs from your login shell. Spell out full paths for commands, scripts, and output files, never or relative paths.
• Almost no environment variables. cron's PATH is minimal, so write node, python, or mysqldump as /usr/bin/.... If you need variables, set them at the top of the crontab or source /.bashrc inside your script.
• Make scripts executable: chmod +x script.sh.
• Always log output. By default, output is discarded (or mailed locally). Append >> /path/log 2>&1 so you can confirm the job ran and see any errors.
• Mind the time zone. Check the server's zone with timedatectl; otherwise "3 AM" may not be the 3 AM you expect.

Summary

A crontab entry boils down to "five time fields plus one command." Get three things right and you're set: keep the field order straight, use absolute paths for everything, and redirect output to a log. Start by adding a harmless every-10-minutes test job with crontab -e to confirm it fires, then swap in your real backup schedule and let the server look after itself.