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 requires separate credentials and permissions: if the production server holds backup-deletion credentials, an attacker may still delete off-server copies.
  • Human error protection: an accidental DROP TABLE or bad deploy doesn’t cascade into your only safety net.
Immutable retention can protect stored versions against deletion, but governance and compliance modes have different bypass rules. Verify the storage provider’s exact retention and administrator permissions; do not assume all “immutable” products protect against every privileged account.

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

Before choosing a backup plan, confirm retention, restore charges, credential separation and whether restore testing is included. Off-server storage alone does not prove the restore will work.

A restore drill you can actually record

Choose a non-production test environment and a backup timestamp. Do not overwrite the live site to test your only copy. For a database-backed site, restore both files and a transactionally consistent database; a filesystem archive taken during database writes may not be sufficient.

  1. Record the backup job ID, creation time, size, encryption-key location and required restore software.
  2. Download using a recovery identity that is independent of the production host. Confirm you can access required keys without relying on the failed server.
  3. Verify the archive or provider integrity check, then restore into an isolated environment. Block outbound email, payment capture, webhooks and scheduled jobs before starting a restored production application.
  4. Check expected files, database tables, an older and newer content item, and account access. Hashes help detect transfer corruption but do not prove application consistency.
  5. Measure elapsed recovery time and the age of the newest recovered transaction. Compare those observations with your recovery-time and recovery-point requirements.
  6. Record failures, fix them, repeat the drill, then securely remove the test environment and its copied customer data.

An example record might read “Backup 2026-10-20 02:00 UTC; isolated restore started 10:00; application checks finished 10:42; newest order 01:57.” These are invented demonstration values, not our recovery results. The 42-minute drill is not a production recovery guarantee.

Questions to resolve before relying on retention

How many daily versions survive a missed payment? Does deletion of a production account remove its backups? Who can shorten retention? What happens to encrypted copies if a key is lost? What is the restore procedure if both your server and your usual administrator account are unavailable? Document answers outside the production host.