How to Automate Server Backups (And Actually Test Them)

This page may contain affiliate links.

Let's be honest: everyone knows they should back up their server. But most of us treat backups like a gym membership — we set it up once, feel virtuous, and then never actually check it works. Then the day comes when you accidentally run rm -rf on the wrong directory, or your hosting provider has a catastrophic failure, and you discover your 'backup' was silently failing for six months. This guide will show you how to automate server backups properly and, more importantly, how to test them so they're actually there when you need them.

1. Choose Your Backup Strategy (Don't Overthink It)

The best backup strategy is the one you'll actually maintain. For most home labs and small business servers, a '3-2-1' approach is ideal: three copies of your data, on two different types of media, with one copy off-site. For a UK homelabber, that might look like:

• Primary copy: Your live server data (obviously).
• Second copy: An external USB drive or NAS on your local network.
• Third copy: Encrypted cloud storage — think Backblaze B2, Wasabi, or even an S3-compatible bucket. Prices vary, but you're typically looking at a few pounds per terabyte per month, which is cheaper than a round of drinks.

Don't get bogged down in enterprise-grade software. Tools like restic, borgbackup, or even plain rsync with hardlinks are more than enough. My personal favourite is restic because it does deduplication and encryption out of the box, and it works with most cloud storage providers.

2. Write a Backup Script That Actually Makes Sense

Here's a simple, robust backup script using restic. Save it as /usr/local/bin/backup.sh and make it executable with chmod +x.

#!/bin/bash
set -euo pipefail

# Variables
export RESTIC_REPOSITORY='s3:s3.eu-west-2.wasabisys.com/my-backup-bucket'
export RESTIC_PASSWORD='your-strong-password-here'
BACKUP_PATHS='/var/www /etc /home'

# Backup to cloud
restic backup $BACKUP_PATHS

# Prune old snapshots (keep 7 daily, 4 weekly, 6 monthly)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

# Also do a local backup to external drive
rsync -a --delete /var/www /mnt/usbdrive/www/
rsync -a --delete /etc /mnt/usbdrive/etc/

Set this to run daily via cron. Open your crontab with crontab -e and add:

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

That runs it at 2am every day. The set -euo pipefail line means the script will fail loudly if anything goes wrong — which is exactly what you want. Don't let errors slip through silently.

3. Automate the Testing (This Is the Part Everyone Skips)

Here's the uncomfortable truth: a backup you've never restored from is not a backup — it's a hope. You need to automate testing, not just do it manually every few months. The trick is to restore to a throwaway directory and verify the data is intact.

For restic, you can add this to your backup script or a separate test script:

#!/bin/bash
set -euo pipefail

export RESTIC_REPOSITORY='s3:s3.eu-west-2.wasabisys.com/my-backup-bucket'
export RESTIC_PASSWORD='your-strong-password-here'

# Restore latest snapshot to a temp directory
LATEST=$(restic snapshots --latest 1 --json | jq -r '.[0].id')
restic restore $LATEST --target /tmp/restore-test

# Check a few key files exist and are non-empty
if [ ! -s /tmp/restore-test/var/www/index.html ]; then
  echo "ERROR: Restore test failed - missing or empty file"
  exit 1
fi

echo "Restore test passed at $(date)"
rm -rf /tmp/restore-test

Add this to cron too — perhaps weekly on a Sunday morning. If it fails, you'll get an email via your cron daemon (or you can pipe it to a notification service like ntfy.sh or a Slack webhook). The point is: if the test fails, you know about it within hours, not months.

For rsync-based backups, the test is simpler — just compare file counts or checksums. Something like:

diff -r /var/www /mnt/usbdrive/www/ && echo "Local backup OK" || echo "Local backup MISMATCH"

That's crude but effective. You'd be amazed how often a USB drive silently unmounts or fills up.

4. Monitor, Alert, and Don't Trust Your Eyes

If you're like me, you'll check the logs once, then never again. That's why you need automated monitoring. The simplest UK-friendly approach is to use healthchecks.io — it's free for basic use, and it works by expecting a 'ping' from your backup script at a set time. If the ping doesn't arrive, you get an email alert.

Add this to the end of your backup script:

curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

If you prefer self-hosting, Uptime Kuma can do the same thing — it's a brilliant open-source tool that runs on a Raspberry Pi or a £5-a-month VPS. You can even get push notifications to your phone via the Uptime Kuma app. Honestly, the cost of a small VPS or a Pi is nothing compared to the cost of losing your data.

One more tip: make your backup script emit a clear success message with the backup size and duration. That way, if you do glance at the logs, you can quickly spot anomalies like 'backup completed in 2 seconds' — which usually means nothing was backed up.

Now, if you're thinking 'this all sounds great but I don't want to write all these scripts from scratch' — that's exactly why I put together the Home Lab & Automation Pack. It's a set of ready-made AI prompts for scripting, troubleshooting and documenting your homelab, from just £9. You paste in what you're trying to do, and it gives you the exact script or commands — including backup and restore test routines like the ones above. It's a genuine shortcut if you'd rather skip the trial-and-error phase.

5. Test a Full Disaster Recovery (At Least Once a Year)

Automated restore tests are great, but they only check that files exist. They don't check that your server can actually boot from those files. So once a year, do a proper disaster recovery drill. Spin up a fresh VPS or use a spare machine, and restore everything from scratch. Follow your own documentation — if you don't have documentation, write it now. This is the ultimate test.

Here's the drill:

1. Provision a new server (or reinstall your existing one).
2. Install the OS and required packages.
3. Restore your config files from backup.
4. Restore your data from backup.
5. Start your services and check everything works.
6. Time yourself. If it takes more than a few hours, you need better documentation or a more streamlined process.

Do this on a Saturday morning with a cuppa. Yes, it's tedious. But it's the single best way to ensure you're not the person posting on Reddit at 3am asking 'can I recover from a corrupted ZFS pool?' (Spoiler: the answer is usually no.)

Conclusion

Automating backups is easy. Automating backup tests is what separates people who've never lost data from people who've lost data once and learned their lesson. Set up a solid 3-2-1 strategy with restic or rsync, schedule daily backups, add weekly automated restore tests, and monitor everything with healthchecks or Uptime Kuma. Then do one full disaster recovery drill a year. It's a few hours of work upfront, but it buys you the peace of mind that when your server dies — and it will, eventually — you'll be back up and running before your tea goes cold. Your future self will thank you.