img

Backups & Recovery Plan: What Stands Between You and Starting Over

Here’s a conversation I’ve had more times than I’d like.

A business owner calls because their site is down…hacked, defaced, redirecting visitors to a pharmacy in Eastern Europe, something weird. We talk through options and I ask the obvious first question: Do you have a backup?

The answer is almost always “I think my host does that.” And the host usually does…sort of. A single snapshot, overwritten every 24 hours, stored on the same server as the site itself. If the server goes down, the backup goes with it. If the site was compromised three days ago and nobody noticed, that snapshot is just a clean copy of the infection.

That’s why that kind of setup isn’t really a backup strategy at all.


What Actually Goes Wrong

The dramatic version is a full-blown hack — malware injected, admin accounts hijacked, customer data exposed. That happens, and I’ve cleaned up plenty of them. But most backup emergencies are quieter than that:

  • A plugin update breaks the site. You update WooCommerce on a Friday afternoon and your checkout page throws a white screen. Without a pre-update snapshot, you’re debugging live — or waiting on a developer who charges by the hour.

  • Someone overwrites the wrong thing. A well-meaning team member replaces the homepage banner and accidentally deletes the page content. The host’s daily backup already ran, so the old version is gone.

  • The host has a bad day. Shared hosting providers pack hundreds of sites onto a single machine. Hardware fails. Disks corrupt. Migrations go sideways. If your only backup lives on that same machine, it’s not a backup — it’s a second copy of the same risk.

  • A compromise goes unnoticed for weeks. Malware doesn’t always announce itself. I’ve seen infections with dwell times measured in months — a credit card skimmer silently harvesting data, SEO spam pages indexed by Google before anyone on the team notices. By the time the host’s rolling snapshot catches up, every available backup is dirty.

The pattern is the same every time: the backup that existed wasn’t the backup they needed.


What I Actually Set Up

My backup system is built around a principle I’ve learned the hard way: the backup only counts if it’s somewhere else, it’s encrypted, it’s tested, and it goes back far enough.

Here’s what that looks like in practice:

Five stacked service cards describing backup infrastructure components: daily snapshots, off-site storage, encryption, retention depth, and tested restores.

Daily automated snapshots

Your entire site — files, database, configuration — copied every night on a schedule, unattended. You don't have to remember, click anything, or check a dashboard.

Off-site storage, separate from your server

Backups are sent to a different datacenter entirely. If your server catches fire — figuratively or literally — your backup is untouched, sitting on isolated object storage with its own redundancy.

Encryption at rest and in transit

Backups are encrypted before they leave the server and stay encrypted in storage. If someone somehow accessed the storage bucket, they'd find ciphertext, not your database credentials.

Retention depth, not just recency

A single daily snapshot isn't enough when infections go unnoticed. A rolling window — daily snapshots going back weeks, plus weekly snapshots going back further — so we can reach past a compromise to find a clean restore point. The exact window depends on your site, and we'll figure out the right depth together.

Tested restores

A backup you've never tested is a hope, not a plan. Periodic verification that backups actually restore to a working state — not just that the files are there, but that the site boots, the database is intact, and the content is current. You'll never find out your backups are broken on the day you need them.


What Recovery Actually Looks Like

When something goes wrong, the goal is measured in minutes, not days.

If a plugin update breaks your site, I can roll back to the pre-update snapshot — typically within 15 to 30 minutes from the time you reach out. Your visitors see a brief maintenance page, not a white screen.

If malware is involved, I identify how far back the compromise goes, find the last clean snapshot, restore it, then harden the entry point that was exploited. That’s a longer process — hours, not minutes — but the backup is what makes it possible at all. Without one, the conversation shifts from “let’s restore” to “let’s rebuild,” and that’s a different timeline and a different invoice.

If it’s a simple content accident — a deleted page, an overwritten image — I can pull just the affected files from backup without touching the rest of the site.


Why Host Backups Aren’t Enough

I don’t say this to badmouth hosting companies. Some of them do a decent job. But “decent” and “reliable” aren’t the same thing when your business is on the line.

Most shared hosting backups are a courtesy feature — included free, configured by default, and maintained with the same priority as everything else that’s free. That means single-copy snapshots, stored locally, with short retention, no encryption, and no guarantee they’ll actually work when you try to restore. The support ticket for a restore often takes longer than the outage itself.

Managed hosting providers like Kinsta or Cloudways do better — daily snapshots with 14- or 30-day retention, one-click restores. That’s a real step up. But even then, the backups live within the same provider’s ecosystem. If your account is suspended or the provider has an incident, access to those backups can be interrupted exactly when you need them most.

An independent backup — one that you control, stored somewhere separate — is what closes that gap.


What This Costs You (And What Skipping It Costs)

Backups are one of the most affordable pieces of a security posture, and one of the most expensive to skip.

The monthly cost of automated, encrypted, off-site backups is a fraction of what a single emergency rebuild would run. And rebuilds aren’t just expensive in dollars — they cost you time, search rankings, customer trust, and the specific content and configuration that made your site yours.

I’ve worked recoveries where the client had no usable backup at all. We rebuilt from the Wayback Machine, screenshots, and memory. It took days. The bill was significant. And the result was still a rough approximation of what they’d had before.

A backup would have made that a same-day fix.


Get a Clear Picture Before Anything Goes Wrong

If you’re not sure what your current backup situation looks like — whether your host is actually running them, where they’re stored, how far back they go — that’s worth finding out now, while everything is still working.

My free security scan includes a look at your backup posture alongside vulnerabilities, authentication, and hosting configuration. No commitment, no pitch — just a honest read on where you stand and what’s exposed.


Related Reading