Monitor Database Backup Cron Jobs

The Problem

Database backups are the last line of defense. They run quietly in the background — pg_dump, mysqldump, or a custom script uploading to S3. When they work, you never think about them.

When they fail, you find out at the worst possible moment:

• Disk full — backup couldn't write
• Credentials changed — database connection failed
• S3 bucket policy updated — uploads silently rejected
• Server rebooted — crontab wasn't restored

You check the backup storage: last successful backup was 3 weeks ago.

The Solution

Add a heartbeat ping at the end of your backup script. If the backup completes successfully, it pings CronSignal. If it doesn't ping on schedule, you get an alert.

PostgreSQL Example

#!/bin/bash
set -e

# Backup PostgreSQL
pg_dump -h localhost -U postgres mydb > /backup/mydb_$(date +%Y%m%d).sql

# Compress
gzip /backup/mydb_$(date +%Y%m%d).sql

# Upload to S3
aws s3 cp /backup/mydb_$(date +%Y%m%d).sql.gz s3://my-backups/

# Clean up old local backups (keep last 7 days)
find /backup -name "*.sql.gz" -mtime +7 -delete

# If we got here, everything worked — ping CronSignal
curl -fsS https://api.cronsignal.io/ping/YOUR_CHECK_ID

MySQL Example

#!/bin/bash
set -e

# Backup all databases
mysqldump --all-databases > /backup/all_$(date +%Y%m%d).sql

# Compress
gzip /backup/all_$(date +%Y%m%d).sql

# Upload to remote storage
rsync -az /backup/all_$(date +%Y%m%d).sql.gz backup-server:/backups/

# Success — ping
curl -fsS https://api.cronsignal.io/ping/YOUR_CHECK_ID

MongoDB Example

#!/bin/bash
set -e

# Backup MongoDB
mongodump --out /backup/mongo_$(date +%Y%m%d)

# Compress
tar -czf /backup/mongo_$(date +%Y%m%d).tar.gz /backup/mongo_$(date +%Y%m%d)

# Upload
aws s3 cp /backup/mongo_$(date +%Y%m%d).tar.gz s3://my-backups/

# Cleanup
rm -rf /backup/mongo_$(date +%Y%m%d)

# Ping on success
curl -fsS https://api.cronsignal.io/ping/YOUR_CHECK_ID

Crontab Setup

Schedule your backup with output logging:

# Run backup at 2 AM daily
0 2 * * * /home/admin/scripts/backup.sh >> /var/log/backup.log 2>&1

The ping is already in the script, so you don't need && curl in the crontab line.

Setting the Right Grace Period

In CronSignal, set the grace period based on how long your backup typically takes, plus a buffer:

• Small database (< 1GB): Schedule every 24h, grace period 30 min
• Medium database (1-10GB): Schedule every 24h, grace period 1 hour
• Large database (10GB+): Schedule every 24h, grace period 2-3 hours

If your backup takes 45 minutes on average, a 1 hour grace period gives you 15 minutes of buffer before alerting.

What Gets Monitored

With this setup, CronSignal alerts you when:

• Backup never started: Cron didn't run (server down, crontab missing)
• Backup failed: Script errored before reaching the ping (set -e ensures this)
• Backup hung: Script started but never completed
• Upload failed: Database dump worked but S3/rsync failed

Pro Tips

Verify Backup Integrity

Don't just check if the file exists — verify it's valid:

#!/bin/bash
set -e

pg_dump mydb > /backup/mydb.sql

# Verify the backup is valid SQL
psql --set ON_ERROR_STOP=on -f /backup/mydb.sql template1 < /dev/null

# If verification passed, upload and ping
aws s3 cp /backup/mydb.sql s3://my-backups/
curl -fsS https://api.cronsignal.io/ping/YOUR_CHECK_ID

Alert on Backup Size Changes

A suspiciously small backup might mean something's wrong. Check size before pinging:

#!/bin/bash
set -e

pg_dump mydb | gzip > /backup/mydb.sql.gz

# Minimum expected size: 10MB
MIN_SIZE=10000000
ACTUAL_SIZE=$(stat -c%s /backup/mydb.sql.gz)

if [ $ACTUAL_SIZE -lt $MIN_SIZE ]; then
    echo "Backup too small: $ACTUAL_SIZE bytes (expected > $MIN_SIZE)"
    exit 1
fi

aws s3 cp /backup/mydb.sql.gz s3://my-backups/
curl -fsS https://api.cronsignal.io/ping/YOUR_CHECK_ID