Backups, Recovery, and the One Mistake That Wipes Years of Work — What Your Website Is Doing While You Sleep (Part 1)

What your website is doing while you sleep

Most owners think about their website only when they’re using it. They open the homepage, check the latest blog post, look at the contact form. Whatever they see in those moments is what the website “is” to them.

That’s the surface. Underneath, the website is software running 24 hours a day. It’s responding to requests from real users, search engine crawlers, security scanners, and the occasional malicious bot. It’s storing data, sending emails, syncing with third-party services, generating cache files, and accumulating logs. Most of that activity happens at hours nobody’s watching.

This is Part 1 of a six-part series called What Your Website Is Doing While You Sleep. Each part covers one of the things running in the background that, when it goes wrong, costs owners their business. We’re starting with the one that’s caused more outright disasters than any other: backups, recovery, and the one mistake that wipes years of work.

The thing nobody believes until it happens to them

Every website goes down eventually. Not because of bad luck. Because the things that can take down a website — failed updates, hosting issues, malware, accidental deletions, a developer’s typo — are common enough that “it’ll never happen to me” is a math error.

The question isn’t whether something will happen. It’s whether you’ll be ready when it does.

I’ve taken over sites where the owner had no backups, no version history, and no working copy of the files on their own machine. The site went down. The hosting company didn’t have a recent backup. The owner had three years of blog posts, customer testimonials, and SEO work — gone. Not “we can probably get most of it back.” Gone.

If you remember nothing else from this post, this: your backup strategy is one of the only things standing between you and that scenario. Most owners don’t have one. Most of the ones who think they do, don’t.

What “having backups” actually means

The phrase gets thrown around loosely. Let me define it properly. A real backup strategy has four properties:

1. Automated. Backups happen on a schedule without anyone touching anything. Manual backups don’t count. You’ll forget.
2. Off-site. The backup lives somewhere your hosting account doesn’t. If your host gets compromised, you can’t trust backups stored on the same host.
3. Recent. A backup from six months ago is barely a backup. Daily for active sites, weekly minimum for static ones.
4. Tested. You’ve actually tried to restore from a backup at some point and confirmed it worked.

Three out of four isn’t passing. The fourth one — testing — is what most owners skip, and it’s where most “I have backups” stories fall apart.

The three things that need backing up

A WordPress site has three layers, and a real backup includes all three:

1. The database

This is where your posts, pages, comments, settings, and most user content live. If you lose the database, you’ve lost the words on every page. Site files alone won’t recover this; the database has to be backed up separately.

2. The wp-content folder

This is where your themes, plugins, and uploaded media files live. Lose this and your images are gone, your theme is gone, and any plugin customizations vanish. The database knows what should be there but the actual files have to be restored from a backup.

3. The WordPress core and configuration

The core WordPress files plus wp-config.php. Less critical because WordPress core can be reinstalled, but wp-config.php contains your database credentials and security keys. Worth keeping.

A complete backup includes all three. “I have backups” but only the database, or only the files, isn’t a complete backup. It’s a partial one, and the recovery from a partial backup is its own kind of headache.

How to actually do this

Three paths, ranked by how much you have to manage yourself.

Path 1: Managed hosting that handles backups (easiest)

Most modern managed WordPress hosts (Kinsta, WP Engine, Cloudways, Pressable, SiteGround’s higher tiers) include automated daily backups stored off-site as part of the hosting package. They also typically include one-click restore.

This is the simplest version of “backups are handled.” It’s also why most owners on cheap shared hosting are more exposed than they realize — those plans often don’t include backups, or include only manual ones the host won’t help you restore.

If you’re on shared hosting and you’ve never specifically confirmed backup terms, do that today. Email your host. Ask: “Do you take automated daily backups stored off-site? How long are they retained? How do I restore from one?” Whatever the answer is, you now know.

Path 2: A backup plugin (middle ground)

If your host doesn’t handle backups, a plugin can. The ones I trust:

• UpdraftPlus. Free version handles automated backups to Dropbox, Google Drive, Amazon S3, or other off-site storage. Paid version adds incremental backups and one-click restore.
• BlogVault. Paid only, but does real-time incremental backups, off-site storage, and tested restores. More reliable than free options for sites that matter.
• Solid Backups (formerly BackupBuddy). Long-running paid option, similar feature set.

The pattern is the same: install, configure off-site destination, set automated schedule, test the restore once. If the plugin can’t restore from its own backup, it isn’t a backup.

Path 3: Server-level backups (advanced)

If you’re technical (or your developer is), server-level backups via cPanel, Plesk, or your VPS provider’s snapshot feature are the most complete. They capture the entire server state, not just the WordPress site. They’re also the most awkward to restore from for non-technical owners.

This is the path most agency-managed sites are on. Our WordPress maintenance service uses a combination of host-level snapshots plus plugin-level WordPress backups for redundancy — two backup systems running in parallel so a failure of one doesn’t take you down.

The “tested” part most people skip

Here’s the part that exposes most “I have backups” claims: the test. A backup that’s never been restored is theoretical. The number of stories I’ve heard where the backup file existed but couldn’t be restored — corrupted, incomplete, missing the database, version mismatch — would shock you.

The test costs nothing. It just requires doing it once:

1. Spin up a free staging environment (most managed hosts include one; some plugins like Local by Flywheel run one on your laptop).
2. Restore your most recent backup to that staging environment.
3. Browse the staging site. Make sure pages load, images appear, plugins work, the database is intact.
4. If something’s missing, your backup is incomplete. Find out what’s missing and fix the backup configuration.

Run this test once a quarter. Most owners never run it. Most “I have backups” stories that go badly are people who never tested.

The one mistake that wipes everything

The single most common cause of total data loss for small business WordPress sites isn’t a hack. It isn’t a hosting failure. It’s the owner — or someone with admin access — making a destructive change without a recent backup as a fallback.

The pattern repeats:

• Owner installs a new plugin, it conflicts with an existing one, the site crashes.
• Developer pushes an update, fat-fingers a database query, deletes content.
• An employee accidentally deletes a section of a key page and saves.
• A theme update overwrites customizations.

If a recent backup exists, the fix is restore-and-redo. If a recent backup doesn’t exist, the fix is “rebuild from scratch and hope you remember what was there.” That’s the “wipes years of work” scenario in the title.

The protection is two layers:

• Daily automated backups. So even a same-day mistake can be rolled back to last night’s state.
• A pre-change manual backup before any major work. Updating plugins, switching themes, editing the database — make a backup right before. Most plugins make this a one-click operation.

Belt and suspenders. The cost is 60 seconds of your time. The cost of not having them when you need them is sometimes the entire site.

The Friday-afternoon audit

Twenty minutes, your hosting account, your WordPress admin, an honest assessment:

1. Where are your backups stored? Name the location. If you can’t, you don’t have a backup strategy.
2. How recent is the most recent backup? If it’s more than 7 days old, the schedule isn’t running.
3. Is the backup off-site? If it’s stored in the same hosting account as the live site, it’s only half a backup.
4. Have you ever restored from a backup successfully? If no, run the test this quarter.
5. Who else has admin access to this site? Anyone with admin can accidentally cause the disaster the backups are protecting against. Audit the user list.

Whatever you can’t answer is the gap. Fix that one before next week.

What’s coming in Part 2

Part 2 of this series picks up the next thing your website is doing while you sleep — handling speed and caching. The background tax most sites pay without realizing it, why the typical “speed optimization” misses the point, and how to tell if your caching layer is actually doing its job.

Final Thoughts

Backups are the boring infrastructure of running a website. Nobody notices when they’re working. Everyone notices when they’re not, and by then it’s too late.

Five minutes this week: confirm where your backups live, how recent they are, and whether they’ve been tested. If any of those answers is “I don’t know,” that’s the gap. Close it before something forces you to.