A simple backup script isn’t a disaster recovery strategy. Learn why your `cp` or `pg_dump` command is a time bomb and discover robust, real-world solutions that will actually save you when things go wrong.

Your Backup Script is a Ticking Time Bomb. Here’s Why.

I still get a cold sweat thinking about it. It was 3 AM, naturally. A PagerDuty alert screamed about database corruption on `prod-db-01`. “No problem,” I thought, still half asleep. “I’ll just restore from last night’s backup.” I navigated to the backup directory, feeling like a hero, only to find a `db_backup.sql` file that was 0 kilobytes. The cron job had failed silently for weeks because the disk filled up halfway through the dump, and since no one was checking the script’s exit code or `stderr`, we were flying blind. That was the night I learned the hard way that a backup script is not a backup strategy. A backup is only real if you can successfully restore from it.

Why “Just Copying The Files” Is A Recipe For Disaster

I see this question pop up all the time, and it comes from a good place: trying to find a simple solution to a complex problem. The core misunderstanding is the difference between a file and a state. Your application, especially your database, is a living, breathing thing. It has data in memory, transactions in flight, and files that are locked.

Simply running cp -r /var/lib/mysql /backups/ while the database is running is like taking a photo of a sprinter mid-race. You’ll get a blurry, inconsistent picture. Some files will be from one moment, others from another. When you try to restore this, the database will likely refuse to start, complaining about corruption. A true backup needs to be consistent and atomic—a perfect snapshot of a single moment in time.

The Tiers of a Real Backup Strategy

Let’s move from hope to engineering. Here are three approaches, from a quick patch to a system you can actually bet your job on.

1. The “Get Me Through The Night” Fix: Hardening Your Script

Okay, you have a simple shell script and you can’t re-architect everything right now. Fine. Let’s at least make it less likely to silently fail. This is the hacky-but-effective approach.

Instead of a naive database dump like this:

# BAD: What happens if this fails? Where do errors go?
pg_dump my_awesome_app > /mnt/backups/db.sql

You need to add error handling, compression, and proper command flags. A slightly better version looks like this:

#!/bin/bash
set -eo pipefail

# GOOD:
# - 'set -eo pipefail' stops the script on any error.
# - pg_dumpall gets everything: roles, tablespaces, etc.
# - We compress the output to save space.
# - We timestamp the file.
# - We log errors to a separate file.
pg_dumpall -U postgres | gzip > /mnt/backups/postgres-$(date +%F).sql.gz 2> /var/log/backups/last_run.log

For files, stop using cp. Start using rsync. It’s faster, more efficient, and the -a (archive) flag is critical for preserving permissions, ownership, and modification times.

# Instead of: cp -r /var/www/my-app /mnt/backups/
# Use rsync:
rsync -avz --delete /var/www/my-app/ /mnt/backups/www-latest/

Warning: This is still a band-aid. Your backups are on the same server, you have no version history (it gets overwritten each night), and you aren’t testing the restores. It’s a step up from nothing, but don’t get comfortable.

2. The “I Want To Sleep At Night” Fix: A Real Backup Tool

This is the permanent fix. You stop writing custom scripts and use a dedicated tool built by people who have already experienced all the painful failure modes. My weapon of choice for this is often Restic, but others like Borg or Duplicacy are great too.

Why is this so much better? These tools give you:

• Deduplication: Only changed blocks are stored, saving immense space.
• Encryption: Backups are encrypted at rest before they even leave your server.
• Off-site Storage: They natively support pushing backups to cloud storage like AWS S3, Wasabi, or Backblaze B2. If your server burns down, your backups don’t.
• Snapshots & Pruning: Easily keep multiple versions (e.g., 7 daily, 4 weekly, 6 monthly) and automatically delete old ones.

A typical workflow on `prod-web-01` would look like this:

# One-time setup (with credentials for S3 bucket)
export AWS_ACCESS_KEY_ID="YOUR_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET"
restic -r s3:s3.amazonaws.com/techresolve-backups/prod-web-01 init

# Daily cron job
restic -r s3:s3.amazonaws.com/techresolve-backups/prod-web-01 backup /var/www/ /etc/nginx/

# Pruning old backups (run weekly/monthly)
restic -r s3:s3.amazonaws.com/techresolve-backups/prod-web-01 forget --keep-daily 7 --keep-weekly 4 --prune

This is a professional setup. It’s automated, versioned, secure, and off-site.

3. The “Break Glass In Case of Emergency” Fix: Volume Snapshots

Sometimes, you need a full-system rollback, and you need it now. This is where block-level volume snapshots come in. Whether you’re using AWS EBS, DigitalOcean Volumes, LVM, or ZFS, this is your ultimate safety net.

A volume snapshot is an instantaneous, point-in-time copy of the entire disk. It’s the most reliable way to capture the exact state of a machine at a specific moment. You can then launch a brand new server from that snapshot in minutes.

This is my “nuclear option” because while it’s incredibly powerful, it can be expensive and doesn’t give you the granular, file-level restore capabilities of a tool like Restic. It captures the whole disk, warts and all. For a database, this results in what’s called a “crash-consistent” backup. The database will think it just lost power. It will almost always recover cleanly by replaying its journal, but it’s not as graceful as a proper `pg_dump`.

Comparing The Approaches

So, is a backup as simple as copying a file? Absolutely not. It’s about guaranteeing recoverability.

My Final Pro Tip: A backup you haven’t tested is just a rumor. Schedule regular, automated restore tests to a staging environment. It’s the only way to know for sure that you’re protected. Don’t wait for a 3 AM catastrophe to find out your strategy was based on hope.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions