Your WordPress Site Will Fail the Day You Skip Backups

A WordPress site rarely dies in a dramatic hack. It dies on a Tuesday when the host has a disk failure, an update throws a white screen, and the owner discovers the last backup is six months old — or never existed.

If you own a live site and you cannot restore it in under an hour, you do not have a backup. You have a hope.

This is the owner checklist. Not a plugin roundup. Not a course. The minimum that keeps a site recoverable.

What a real backup actually contains

A screenshot of the homepage is not a backup. A zip of the theme folder is not a backup. You need three pieces, together, from the same moment in time:

1. The database. Posts, pages, users, settings, WooCommerce orders, form entries.
2. The files. wp-content at minimum: themes, plugins, uploads. Prefer a full install so wp-config.php is not a mystery later.
3. The proof. A restore test on a staging copy or a throwaway subdomain. An untested backup is a rumor.

If any one of those is missing, the restore will stall. That is how sites stay down for days.

The weekly owner loop

Do this on the same day every week. Fifteen minutes is enough if the tooling is already in place.

• Confirm the last successful backup finished, and that the file size did not suddenly drop to almost nothing.
• Confirm an off-site copy exists. Same-server backups die with the server.
• Glance at core, theme, and plugin update notices. Apply them on staging first when the site earns money.
• Check that SSL is valid and the site loads on a phone, not only on your laptop.
• Write down one line: date, backup status, anything that looked off.

That last line is the difference between “I think we backed up” and “we can prove it.”

Off-site or it does not count

Keep at least one copy somewhere the host cannot delete:

• Object storage or a dedicated backup provider
• A second region, not the same rack
• A copy you control (an encrypted drive is fine for a tiny brochure site)

Hosting snapshots help. They are not a strategy by themselves. Hosts get sold, accounts get suspended, and “we keep 7 days of snapshots” is useless on day 8.

If you are still deciding where the site should live, start with the comparison of managed .com versus self-hosted. The backup story changes with that choice. Managed platforms often handle snapshots for you. Self-hosted means you own the restore drill.

Updates without the white screen

Updates are not optional. They are also not “click Update All on production at midnight.”

• Back up first. Always.
• Update staging. Click the money paths: checkout, forms, login, the page that pays rent.
• Then update production.
• If something breaks, restore. Do not debug live for an hour while customers bounce.

Version day is when this matters most. When a new release lands, the useful work is the owner checklist — not a recap of the marketing page. That is the same posture as the 7.1 owner guide.

Security that is boring on purpose

Most “I got hacked” stories start with stale software, a reused password, and no 2FA on the host and admin accounts.

Do the boring list:

• Unique admin password and 2FA on WordPress, hosting, and email.
• Delete unused themes and plugins. Idle code is still attack surface.
• Limit login attempts. Hide nothing magical; just stop the brute-force noise.
• Keep PHP on a supported version. Hosts that freeze you on an old runtime are a risk, not a bargain.

A leaner install is easier to restore. That is the quiet cousin of the plugin stack problem: fewer moving parts, fewer ways to fail a restore.

The restore drill you should run once

Pick a weekend. Spin up a cheap staging site. Restore last night’s backup onto it. Time it.

You are looking for three answers:

• How long did it take?
• What broke (permalinks, SSL, cron, uploads path)?
• Could a second person follow the notes if you were unavailable?

If the answer to the last one is no, the notes are the real gap. Write them. Store them next to the backup credentials, not in your head.

A one-page policy for clients

If you build sites for other people, this belongs in the handoff, not in a slide deck:

• What is backed up, where, and how often
• Who is responsible after launch
• How to request a restore
• What is out of scope (lost files the client uploaded after the last job)

That is the adult version of “I learned WordPress.” Courses do not keep a bakery online. Restore notes do. If you are still collecting skills instead of shipping work, the other half of this argument is get a first client.

What to ignore

• Daily emails from five different security plugins that all say “critical”
• “Unlimited backups” that never leave the same server
• Anyone who tells you snapshots replace a tested restore

Keep the stack small. Keep one off-site copy. Test it once. Then go back to doing the work the site exists for.

The editor you use to build pages still matters. The block editor is enough for most owners. None of that helps if the database is gone.

---

If this saved you an afternoon of panic, you can buy Jstrange a coffee.

More context on what this software actually is lives in the short history.