Skip to main content

How to back up a VPS properly (a strategy that survives real disasters)

Most people discover their backup strategy was wrong at the worst possible moment. The fix is a strategy built around 3-2-1 and — critically — one you have actually tested.

First, the trap: snapshots are not backups

A snapshot on the same provider (or the same server) is a convenience, not a backup. If the account is compromised, the provider has an outage, or you delete the snapshot by mistake, your "backup" is gone with the data. Snapshots are for fast rollback; backups are for survival.

The 3-2-1 rule

  • 3 copies of your data,

  • on 2 different media or systems,

  • with 1 copy off-site.

For a VPS that means: the live data, a copy on separate storage, and a copy somewhere off the machine entirely — ideally at a different provider or in object storage.

What to back up

  • Databases — dump them properly (pg_dump, mysqldump), do not just copy raw files.

  • Application files and uploads — the web root, media, user content.

  • Configuration — Nginx, systemd units, cron, environment files, TLS material.

  • A record of how it was built — a note or script so you can rebuild without the backup.

Where to put the copies

  • Off-site object storage — S3-compatible storage you control is the most flexible target. Point tools like restic or rclone at it.

  • A second server — e.g. a small VPS in a different region.

  • Encrypt backups before they leave the machine — especially off-site.

How to automate it

  1. Dump the database and archive the application files on a schedule.

  2. Encrypt, then upload to your off-site target (restic, rclone, or a scripted S3/SSH push).

  3. Apply retention — keep daily, weekly and monthly copies and prune the rest, so backups do not fill your disk (a full disk takes the live site down).

  4. Alert on failure. A backup that silently stopped three weeks ago is not a backup.

The step everyone skips: test the restore

An untested backup is a hope. Once a quarter, restore to a throwaway server and confirm the site or database actually comes back. Only then do you know you can recover.

Do it in this order

  1. Back up the database + files, off-site, encrypted, on a schedule.

  2. Add failure alerting and retention.

  3. Test a restore.

  4. Document the rebuild so a fresh server is a known quantity.

Related: Backups that actually save you and Backup your data. If you want backups handled for you, Server Management includes a managed backup routine.

← Back to all posts