How to automate backups with cron

Quick answer: Put your backup commands in a script, make it executable, and add a crontab line such as 30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1. Log everything and check the log — a backup that silently stopped running is the classic disaster story.

Overview

cron runs commands on a schedule and is available on every Linux server. The difference between a toy setup and a reliable one is small: absolute paths, output captured to a log, an alert when the job fails, and an occasional restore test.

Before you start

• A backup command that already works when run by hand (see rsync backups).
• Basic familiarity with cron syntax.
• Key-based SSH auth for any remote target — cron cannot type passwords.

Step-by-step guide

1. Create the script /usr/local/bin/backup.sh:

   #!/bin/bash
   set -euo pipefail
   mysqldump --all-databases | gzip > /var/backups/db-$(date +%F).sql.gz
   rsync -az --delete /var/www/ [email protected]:/srv/backups/www/
   rsync -az /var/backups/ [email protected]:/srv/backups/db/
   echo "$(date -Is) backup OK"

2. Make it executable:

   chmod +x /usr/local/bin/backup.sh

3. Schedule it (crontab -e):

   30 3 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

4. Run it once by hand and confirm the log line and remote files appear.
5. Add failure alerts — because of set -e any error aborts the script, so the "backup OK" line missing from the log means failure; a small wrapper can email or ping you.
6. Rotate old dumps so the disk never fills:

   find /var/backups -name 'db-*.sql.gz' -mtime +14 -delete

Common issues

• Works by hand, fails in cron: cron has a minimal PATH — use absolute paths for every binary and file.
• No log, no idea: without >> ... 2>&1 errors vanish; always capture output.
• Overlapping runs: long transfers can collide with the next schedule — wrap the job in flock if runs may exceed the interval.

When to contact support

Backup scripts are customer-managed on Cloud2Y's unmanaged plans, but if jobs fail because the server or network misbehaves (I/O errors, drops at the same time nightly), open a ticket with the log excerpts.

Frequently asked questions

Why does my script work manually but fail in cron?

Cron runs with a minimal environment and PATH, so commands and files must be referenced by absolute paths, and any SSH connection needs key authentication rather than a password prompt.

How do I capture the output of a cron backup job?

Redirect both stdout and stderr in the crontab line, for example ">> /var/log/backup.log 2>&1". Without this, errors disappear and you learn about failures months too late.

How can I prevent overlapping backup runs?

Wrap the job in flock, e.g. "flock -n /tmp/backup.lock /usr/local/bin/backup.sh", so a long transfer cannot collide with the next scheduled run and corrupt the target.

Related articles

• How to configure cron jobs
• How to back up a Linux server with rsync
• How to test backup integrity
• Common backup mistakes

Need a hand? Contact Cloud2Y support →