Spring Cleaning Our WordPress Fleet: Cutting Backup Costs Without Cutting Corners

Field Notes from 2026-05-02. One backup plugin retired. 1,004 database tables dropped. 37% off the monthly storage bill, with the same three layers of protection still standing.

Last month, we sat down and asked ourselves a question that every hosting provider should ask regularly but few actually do: is every tool in our stack actually earning its place?

The answer, it turned out, was no. The tool that wasn't pulling its weight was costing us, and by extension our clients, real money every single month.

This is the story of how we decommissioned a redundant backup plugin across our entire WordPress fleet, dropped over 1,000 database tables, cleaned up nearly a million storage objects, and cut our monthly backup storage costs by 37%. We still have three layers of backup protection. We didn't remove a layer; we replaced one with something better.

When a plugin does a server's job

When you manage a fleet of WordPress sites across multiple servers, you develop layers of redundancy over time. That's generally a good thing. But not all redundancy is created equal, and sometimes a tool that was the right choice three years ago becomes the wrong choice today.

For several years, we ran a WordPress backup plugin on every site in our fleet. It was a per-site incremental backup tool that pushed data to cloud storage directly from within WordPress. When we first deployed it, it filled a genuine gap. Then our infrastructure evolved. Our server platform gained native WordPress backup capabilities that could do the same job without requiring a plugin on every site.

The plugin wasn't sitting there harmlessly. It creates dozens of database tracking tables per installation. Across our fleet, that added up to 1,004 extra database tables cluttering our servers. It was pushing data to cloud storage, contributing to a monthly bill that had crept well past where it needed to be. And it introduced complexity: another plugin to update on every site, another potential point of failure, another thing to troubleshoot when a client's site behaved unexpectedly.

Meanwhile, the server-level WordPress backup tool could handle the same per-site granular backups without any of that overhead. No plugin to maintain. No database tables to accumulate. No WordPress-layer resource consumption during backup runs. Same protection, cleaner implementation.

What the cleanup actually involved

Removing a backup plugin from one site is trivial. Removing it from every site in the fleet, and cleaning up everything it left behind, is a coordinated infrastructure project. Here's what the cleanup looked like in three phases.

Phase 1: Plugin decommission

We deactivated and removed the plugin from every site across our entire server fleet. This was the straightforward part, but it had to be done carefully. You don't bulk-remove plugins without verifying each site is healthy afterward. Every deactivation was confirmed, every site checked. The same fleet scripting tools we use for spam protection deployments and bulk plugin updates handled the rollout.

Phase 2: Database cleanup

This plugin doesn't just create one or two tables. It builds extensive tracking infrastructure in every site's database. Tables for file change monitoring, backup state tracking, revision logging. Across our fleet, that totaled 1,004 database tables that needed to be identified, verified as plugin-specific, and dropped.

We scripted this carefully. Dropping the wrong table in a WordPress database can break a site instantly. Every table was pattern-matched against the plugin's known schema before removal. Zero sites were affected.

Phase 3: Storage cleanup

This was the heavy lift. The plugin had accumulated 931,000+ objects in our cloud storage. Here's the thing about S3-compatible storage: deleting objects doesn't always mean they're gone. With versioning enabled (which you want for backup storage), every deletion creates a "delete marker," and the old versions remain.

The total cleanup involved managing over 2.6 million S3 objects when you count versioned files and delete markers. The mechanism that actually shrinks the bucket is a lifecycle policy, not the delete command itself.

This is the trap most people miss when cleaning up a versioned backup bucket: the delete commands run, the console shows the objects gone, and the monthly bill stays exactly the same. The lifecycle policy is what actually frees the storage. It ran across multiple days as the rules executed.

The result

Metric	Result
Monthly storage cost reduction	37%
Database tables removed	1,004
S3 objects cleaned	931,000+
Total objects managed (with versions)	2.6 million+
Backup layers maintained	Still 3
Sites affected by cleanup	Zero

We cut storage costs by more than a third, removed over a thousand database tables, and cleaned up millions of storage objects, all while maintaining the exact same three layers of backup protection. The difference is that one of those layers now runs at the server level instead of inside WordPress.

Three layers, three different jobs

Every site we host is protected by three distinct backup layers. Each one serves a specific purpose, and none of them overlap.

Layer 1: Per-site WordPress backups (daily, granular)

Every WordPress site gets its own daily backup managed at the server level. These backups are per-site and granular. If one client needs a file restored from yesterday, or their database rolled back after a bad plugin update, we can do that in minutes without touching any other site on the server.

This is your "oops" layer. Someone deleted a page. A plugin update broke the theme. A form entry got lost. Per-site backups handle it quickly and surgically.

The key improvement: this layer used to be handled by a WordPress plugin running inside every site. Now it's handled by our server platform's native WordPress management tools. Same granular protection, but without the plugin overhead, the database clutter, or the storage duplication.

Layer 2: Full subscription backups (server-level)

Each hosting subscription gets its own backup that captures everything: not just WordPress files and databases, but DNS zones, email accounts, server configurations, and all the pieces that make a complete hosting environment work. If Layer 1 handles WordPress-specific problems, Layer 2 handles hosting-level problems: a corrupted DNS zone, a lost email configuration, an entire subscription that needs to be rebuilt.

This layer matters because your website isn't just WordPress. It's the DNS that points your domain to the right server. It's the email accounts your team uses every day. It's the SSL certificates, the cron jobs, the server-side rules. Full subscription backups capture all of it.

Layer 3: Full-server snapshots (disaster recovery)

Independent of per-site and per-subscription backups, every server in our fleet gets complete snapshots pushed to geographically separate storage. This is the "the building burned down" layer. If an entire server were lost (hardware failure, datacenter issue, catastrophic compromise), we can rebuild the entire machine and every site on it.

This is the layer you hope you never need but absolutely must have. It's the difference between "we lost everything" and "we'll have you back online in hours."

The part most hosts skip: we actually test restores

Here's something that doesn't show up in marketing copy but matters more than anything else: we regularly restore from our backups to verify they work. A backup that exists but can't be restored is worse than no backup at all. It gives you false confidence.

We've seen it with clients who came to us from other hosts. They were told they had "daily backups." When something went wrong and they asked for a restore, the backup was corrupted, or incomplete, or the host didn't actually know how to restore it. A backup you've never tested is just a file. A backup you've restored successfully is actual protection.

Three backup mistakes we see most often

After 18 years of managing WordPress sites, since 2007, we've seen nearly every backup failure mode. Three patterns come up again and again.

1. Too many backup plugins

This is the mistake we just fixed in our own stack, so we're not throwing stones. It's genuinely tempting to add backup plugins for extra safety. But multiple backup plugins competing for the same resources cause real problems: they fight over server CPU during scheduled runs, they can lock database tables simultaneously, and they make it unclear which backup is the "real" one when you need to restore.

One well-configured, tested backup system is better than three untested ones running in parallel. Every plugin in your stack should have a clear, non-overlapping purpose.

2. No offsite backup

If your backups live on the same server as your website, you don't have backups. You have a copy. When the server dies, the backups die with it. This sounds obvious, but a startling number of WordPress hosts store backups locally, or on the same network, or in the same datacenter.

Our backup layers push data to geographically separate cloud storage. Your site is in one location; your backups are somewhere else entirely.

3. No restore testing

We covered this above, but it bears repeating. The question isn't "do you have backups?" The question is "when was the last time you successfully restored one?" If the answer is "never" or "I don't know," that backup is Schrödinger's safety net. It might work, it might not, and you won't find out until the worst possible moment.

Why this matters for your hosting bill

You might be wondering why you should care about our internal infrastructure cleanup. Fair question. Here's the direct answer: hosting costs are built on infrastructure costs. When we run a leaner, more efficient operation, that efficiency shows up in the value you get from your hosting plan.

This philosophy extends beyond backups. Every tool, every plugin, every service in our stack gets scrutinized regularly. We include over $10,000 worth of premium plugins with every hosting plan, but only the ones that genuinely improve your site's performance, security, or functionality. We don't pad the number with tools that overlap or go unused. The same operational scrutiny that surfaced six WordPress sites silently running without their object cache applies here: efficiency comes from operating tools, not just installing them.

It's the same reason we wrote about how we handle bot attacks across our fleet, and how we built a fleet-wide email delivery monitor rather than treating outbound mail as fire-and-forget. Transparency about how we operate isn't marketing; it's accountability. When you host with us, you're trusting us with your business's online presence. You deserve to know how we think about that responsibility.

Earn your place in the stack

After 18 years of managing WordPress infrastructure, we've learned that the urge to add tools is strong and the discipline to remove them is rare. Every plugin, every service, every layer needs to answer one question: what specific problem do you solve that nothing else in the stack already handles?

The backup plugin we removed was fine software. It worked as advertised. But "working as advertised" isn't enough when something else can do the same job more efficiently. Once our server platform gained native WordPress backup capabilities that matched what the plugin offered, without the database bloat, without the storage overhead, without another plugin to maintain on every site, the decision was clear.

We didn't reduce our backup coverage. We optimized how it's delivered. Three layers, three distinct jobs, less waste. That's what active infrastructure management looks like.

This applies to everything we deploy across our fleet. Security plugins, caching layers, monitoring tools, the entire technology stack: if a tool doesn't have a clear, distinct job that nothing else handles, it goes. Simpler stacks are faster stacks. Simpler stacks are more debuggable stacks. And simpler stacks cost less to maintain, which means better value for the people who trust us with their websites.

What this means for your site

If you're hosted with WebOps, your site is protected by three layers of backup: daily per-site backups, full subscription backups including DNS and email, and complete server snapshots for disaster recovery. Those backups are tested. Your database isn't cluttered with abandoned tracking tables from plugins we forgot to remove. And your hosting fees reflect an operation that's actively managed, not one that accumulates cruft year after year.

If you're not hosted with us and you're wondering about your own backup situation, ask your current host three questions: Where are my backups stored? How quickly can you restore one? When was the last time you actually did a restore? The answers (or the silence) will tell you everything you need to know.

Is this you?

If you run a WordPress site somewhere other than WebOps, three quick questions will tell you whether your backup setup is real protection or paperwork.

1. Where do your backups physically live, and what is the geographic distance from your live site? If the backups are on the same server, the same network, or even the same datacenter, a single physical event can take both down. Real backup means geographically separate storage.
2. When was the last time you (or your host) successfully restored a backup? Not just "we have backups." A backup you've never restored is a file of unknown quality. A backup you've actually restored is verified protection.
3. If you ran a versioned cloud bucket, do you have a lifecycle policy that expires delete markers and noncurrent versions? If not, every "delete" you've ever run is still costing you money. Storage bills creep up; lifecycle policies make the numbers actually move.

If any of those answers made you uncomfortable, the fix is to treat backups as an operational discipline, not a checkbox.

We're a small operation by design: real humans managing real websites, seven days a week. If you want to talk about your backup strategy, your hosting setup, or anything else about your WordPress site, open a ticket and a human will respond. If you're ready to move to a host that sweats the details, take a look at our hosting plans.