Learning Cron Job - Backup & Maintenance Automation

#Introduction

In episode 9 we built the reliability foundation: lock, retry, idempotency, timeout. Now we apply it to cron's most typical use: backup and maintenance.

Let's set expectations straight first: scheduling a backup is only half the work. A backup that is never verified is not a backup — it's just hope. This episode covers how to schedule backups correctly and at the same time ensure they can actually be restored.

#Scheduled Backups

#rsync: Local Synchronization

rsync is perfect for backing up files to a local disk or another server — and it's naturally idempotent:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
 
30 2 * * * flock -n /var/lock/rsync.lock rsync -avz --delete /data/ backup@nas:/backup/data/ >> /var/log/backup.log 2>&1

--delete makes the target mirror the source (an idempotent operation). Add timeout if the connection often slows down.

#restic: Deduplicated Backup to Storage

restic is a modern backup tool with deduplication, encryption, and snapshots:

30 2 * * * flock -n /var/lock/restic.lock \
    restic -r s3:s3.amazonaws.com/bucket backup /data >> /var/log/backup.log 2>&1

restic secrets (repo password) should not go in crontab — store them in an env file with 600 permissions (we cover this in episode 14):

RESTIC_REPOSITORY=s3:s3.amazonaws.com/bucket
RESTIC_PASSWORD=very-strong-secret

#pg_dump: Database Backup

PostgreSQL backups require pg_dump (logical dump) or pg_basebackup (physical). For small-to-medium databases, a logical dump is enough:

30 3 * * * pg_dump -h localhost -U backup_user -Fc mydb > /backup/mydb-$(date +%F).dump 2>> /var/log/backup.log

Note the 2>> — stderr is appended to the log while stdout (the dump file) is written with >.

#Verifying Backup Results

Backups need to be proven, not assumed. Three levels of verification:

# Di dalam script backup
if [ $? -ne 0 ] || [ ! -s /backup/mydb.dump ]; then
    echo "Backup gagal!" >> /var/log/backup.log
    exit 1
fi

-s ensures the file is not empty. A non-0 exit code means the dump is incomplete.

restic has a built-in verification command — schedule it periodically:

0 4 * * 0 restic -r s3:s3.amazonaws.com/bucket check --read-data >> /var/log/restic-check.log 2>&1

The most important final step: a periodic restore test — restore a backup to a temporary database/file, ideally monthly. If restore is never tested, you won't know the backup works until it's too late.

#Scheduled Maintenance

#logrotate: Rotate Logs (Already Via Cron)

logrotate runs daily via cron on almost every distro:

cat /etc/cron.d/logrotate

Configuration lives in /etc/logrotate.conf and /etc/logrotate.d/. Make sure your cron job logs have their own rules (for example, in episode 5).

#Temporary File Cleanup

Files in /tmp and caches can fill the disk unnoticed:

0 5 * * * find /tmp -type f -mtime +7 -delete >> /var/log/cleanup.log 2>&1

Be careful: don't delete files still in use by other processes — limit by age (-mtime +7) and specific folders.

#Package Updates (With Caution)

Automating apt upgrade or dnf update is risky: an update can break dependencies or trigger service restarts. Safer practices:

• Automate updates only (refresh indexes), not full upgrades.
• Leave upgrades manual or via a CI pipeline with testing.
• If you must automate an upgrade, do it during quiet hours and after a backup.

0 6 * * * apt-get update >> /var/log/apt.log 2>&1

#Backup vs Maintenance Summary

#Closing

Key takeaways:

• Schedule rsync/restic/pg_dump with flock and timeout (episode 9).
• Verify backups: exit code, file size, integrity, and restore test.
• A backup that is never verified is just hope.
• logrotate already runs via cron — just add rules for your logs.
• Clean up /tmp carefully; package updates are best not fully automated.

In episode 11 we'll cover randomization and avoiding peak load — how sleep $((RANDOM % 300)) spreads load, choosing quiet hours of 02.00-04.00, and preventing many backup hosts from knocking over a server all at once!