Most "we lost everything" stories don't start with a missing backup. They start with a backup that was there the whole time — and got wiped along with everything else.

The Problem With On-Server Backups

A nightly backup script that saves a copy to a folder on the same server feels like a backup, but it shares every failure mode of the thing it's backing up. A disk failure, a ransomware infection, or a mistaken rm -rf takes out the backup right along with the original.

The 3-2-1 Rule, Simplified

Keep at least 3 copies of your data, on 2 different types of storage, with at least 1 copy stored somewhere physically separate from the original. The "somewhere separate" part is the piece people skip most often, because it's the least convenient.

What "Off-Server" Actually Buys You

  • Hardware failure protection: a failed drive on your server doesn't touch backup storage elsewhere.
  • Compromise protection: if an attacker gets root on your server, they can't also delete backups they never had access to.
  • Human error protection: an accidental DROP TABLE or bad deploy doesn't cascade into your only safety net.
Immutable backups: Some backup systems go a step further and make backups "immutable" for a set retention window — meaning even an account with full access can't delete or modify them until that window passes. This protects against a compromised admin account being used to wipe backups on purpose.

The Part Everyone Skips: Testing Restores

A backup you've never restored from is a backup you're assuming works. Corrupted archives, missing database tables, and silently failing backup jobs are common enough that periodic test restores should be part of any real backup strategy, not an afterthought.

Setting This Up Without Building It Yourself

Our Cloud Backup plans store copies off-server by default, with retention windows depending on plan tier, and we periodically test-restore backup infrastructure rather than assuming a "completed" backup job actually works.