How to Monitor Automated Database Backups (pg_dump, mysqldump)
Never assume your automated backups are working. A backup strategy without monitoring is just a placebo.
The Anatomy of a Silent Backup Failure
Most developers set up a cron job using pg_dump or mysqldump, pipe it to an .sql file, upload it to an S3 bucket, and forget about it. However, database backup scripts are notoriously prone to silent failures.
Because the cron job runs in the background, a failure does not crash your main web application. Your users won't notice, and your standard website uptime monitors will report 100% health. You will remain completely unaware that your safety net is gone until the day you actually need to restore the database—only to find an empty folder.
Common Reasons pg_dump and Backup Scripts Fail:
- Full Disks: The server runs out of storage space halfway through the dump, resulting in a corrupted, 0-byte file.
- Expired Credentials: The database password was rotated, or the AWS IAM token used to upload to S3 expired.
- OOM (Out of Memory) Kills: The database has grown significantly, and the system terminates the backup process to save RAM.
- Network Latency: The script hangs indefinitely while trying to connect to a remote storage drive.
Bulletproof Your Backups with a Dead Man's Switch
PingPug acts as a dead man's switch for your database routines. Instead of pinging your server to ask if it is awake, PingPug waits for your backup script to report that it successfully finished its job.
If your script usually runs every 24 hours, you configure PingPug to expect a heartbeat ping on that exact interval.
How to Implement PingPug with pg_dump
Implementing PingPug takes 10 seconds. You simply append a native HTTP request to the very end of your bash script using the && operator. Because bash executes sequentially, the curl command will only fire if the pg_dump command exits with a successful 0 status code.
Bash
#!/bin/bash
# 1. Dump the database
pg_dump -U admin -d production_db > /backups/prod_backup.sql
# 2. Upload to S3 (example)
aws s3 cp /backups/prod_backup.sql s3://my-company-backups/
# 3. The PingPug Heartbeat
# This ONLY runs if the above commands succeed.
curl -m 10 --retry 3 https://pingpug.xyz/api/ping/YOUR_UNIQUE_IDIf your disk fills up, or AWS rejects the upload, the script aborts early. The heartbeat is never sent. PingPug notices the silence and immediately sends you an SMS and Email alert, giving you time to fix the backup before a disaster strikes.