Ask most site owners about their backups and you will hear some version of the same sentence: "My host backs it up." It sounds like an answer. It is actually a shrug. When a site gets hacked, a plugin update corrupts the database, or a well-meaning developer overwrites the wrong files, "my host backs it up" is the moment you discover whether you had a backup strategy or just a comforting belief.
The gap between those two things is where real damage happens. Let's close it. This is the 3-2-1 backup rule, why host backups routinely fail the people who lean on them, and what an actual restore drill looks like when your site is on the line.
What the 3-2-1 rule actually says
The 3-2-1 rule is a simple, battle-tested standard borrowed from enterprise IT. For any data you cannot afford to lose, you keep:
- 3 copies of your data — the live site plus at least two backups.
- 2 different media or storage types — so a single technology failure cannot take out every copy at once.
- 1 copy offsite — physically and logically separate from the server your site runs on.
That last number is the one people skip, and it is the one that saves you. A backup stored on the same server as your website is not a real backup. If the server is compromised, the disk fails, or the hosting account is suspended, your "backup" goes down with the ship. Offsite means a different provider, a different account, a different blast radius.
Backups saved inside your hosting account — in a folder like /backups or via a plugin that writes to your own web root — offer almost no protection against the disasters that matter most: server-level compromise, account suspension, or a ransomware event that encrypts everything it can reach. If an attacker gets in, your on-server backups are theirs too.
Why "my host backs it up" is false confidence
Host-provided backups are better than nothing, but they are built for the host's convenience, not your recovery. Here is where they quietly let people down:
1. They are often for the host's disaster, not yours
Many "free" host backups exist so the provider can restore an entire server after their hardware fails. That is not the same as restoring your single site to the state it was in yesterday afternoon. Read the fine print and you will frequently find language like "provided as a courtesy" and "not guaranteed."
2. The retention window is too short
A lot of malware is patient. A site can be infected for days or weeks before the symptoms surface — a spam redirect, a blacklist warning, a sudden traffic collapse. If your host only keeps the last few days of backups, every copy you have may already contain the infection by the time you notice. You restore, and you are still hacked.
3. They are all in one place
Host backups live in the host's ecosystem. Lose access to the account — a billing dispute, a suspension for a terms violation you did not know you tripped, a compromised login — and you lose the site and the backups in the same stroke.
4. Nobody has ever tested a restore
This is the big one. An untested backup is a file, not a recovery. Backups fail silently all the time: the database dump was truncated, the cron job broke three months ago, the archive is corrupt, the plugin excluded wp-uploads to save space. You do not find out until the day you desperately need it to work — the worst possible day to discover it does not.
The only proof that a backup works is a successful restore. Everything before that — the green checkmark, the "backup completed" email, the reassuring dashboard — is a promise the file has not been asked to keep yet.
Applying 3-2-1 to a real WordPress site
Translated out of IT-speak, a solid WordPress backup setup looks like this:
- Copy one — the live site. Your production files and database as they run right now.
- Copy two — an independent backup on different infrastructure. A dedicated backup service or a separate cloud storage bucket, taken on a schedule that matches how often your content changes. A busy store needs far more frequent backups than a brochure site.
- Copy three — an offsite, versioned archive. Stored with a different provider entirely, with enough retention to reach back past a slow-burning infection — think weeks, not hours.
Two things make this actually reliable rather than theatrical:
- Both files and database, every time. A database dump without the wp-content/uploads folder rebuilds your posts with every image broken. Files without the database rebuild a shell with no content. You need both, captured together.
- Versioned retention. Keeping only "the latest" backup means one bad automated capture overwrites your last good copy. Keep a ladder of daily, weekly, and monthly points so you can roll back to before a problem started.
What a real backup and restore drill looks like
A restore drill is the difference between believing you are covered and knowing it. You do not run it on your live site — you prove the backup on neutral ground. Here is the shape of a proper drill:
- Pull the offsite copy. Download the most recent backup from its offsite location — not the on-server one. If you cannot retrieve it cleanly, that is your first finding.
- Restore to a staging environment. Rebuild the site on a separate staging server or local environment. Never test a restore by overwriting production.
- Confirm the database and files landed together. Check that posts, pages, users, settings, and media all came back — not just that the site loads.
- Click through the critical paths. Log in. Load the homepage and key templates. Run a test checkout or form submission. Confirm there are no missing images and no database connection errors.
- Time it. Record how long the full restore took. That number is your real recovery time, and it is what you will quote to a client or your own stress levels during an actual outage.
- Write down what broke. Every drill surfaces something — an excluded folder, an oversized database that timed out, a plugin license that needed reactivating. Fix it before it matters.
Run a restore drill at least quarterly, and any time you make a major change to the site or its hosting. A backup system that has proven itself restorable this quarter is worth more than one that has run flawlessly — and untested — for two years.
Where backups meet security and recovery
Backups and security are two halves of the same seatbelt. Strong WordPress security lowers the odds you ever need a backup; a tested, offsite backup means a breach is an inconvenience instead of a catastrophe. When a site does get hit, clean backups are what let a malware removal or hacked-site cleanup restore known-good content instead of rebuilding from wreckage — provided you have a version from before the compromise.
- The 3-2-1 rule: three copies, two storage types, one offsite. The offsite copy is the one that saves you.
- "My host backs it up" is false confidence — host backups are often short-retention, single-location, and never tested by you.
- A backup on the same server as your site is not a real backup against compromise, suspension, or ransomware.
- Capture files and database together, with versioned retention long enough to reach past a slow infection.
- An untested backup is a guess. Run restore drills on staging, time them, and fix what breaks.
At Wurdey, offsite, versioned backups and periodic restore drills are built into how we care for the sites we manage — not an add-on you have to remember to check. We keep independent copies away from your hosting account, verify they actually restore, and keep retention deep enough to recover from the slow-burning problems, not just the obvious ones. If you would rather know your site is recoverable than hope it is, take a look at our WordPress maintenance packages or get in touch and we will review your current backup setup.
Next step
Rather not do all this yourself?
Wurdey care plans handle updates, backups, security and monitoring for one monthly price, hosting included, from $49 a month. Free migration, and a real team on the other end.