A real backup plan needs exactly three things: it runs automatically without you remembering to trigger it, it's stored somewhere other than the same server your site lives on, and you've actually tested restoring from it at least once. Most WordPress sites have zero of these three, and a lot of the ones that think they're covered actually only have one, usually the first, which turns out to be the least important of the three when disaster actually hits.
This isn't a hypothetical risk. An industry report from WP White Security, cited widely across WordPress security discussions, found that over 60% of WordPress site owners don't perform regular backups until something has already gone wrong and it's too late. This post is the plan for making sure you're not in that 60%.
The three things a real backup plan actually needs
| Requirement | Why it matters | What people usually have instead |
|---|---|---|
| Automated and scheduled | A backup you have to remember to trigger manually eventually doesn't happen; disasters don't wait for you to remember | A one-time manual backup made months or years ago |
| Stored off-site (not on the same server) | If your host's server fails, gets compromised, or your account is deleted, a backup stored on that same server is destroyed along with everything else | A backup folder sitting in the same hosting account, or relying entirely on the host's own backup system |
| Actually tested by restoring it | A backup file can be corrupted, incomplete, or fail during restoration, and you won't know until you desperately need it to work | Trusting a backup exists because a plugin says it ran successfully, without ever opening or restoring it |
Notice that "having a backup" at all isn't actually on this list by itself. A backup that isn't automated, isn't off-site, or has never been tested provides a lot less real protection than it feels like it does.
Why "my host already backs it up" isn't a full answer
This is the single most common false sense of security in WordPress backup planning. Many hosting providers do run their own backup systems, but there are two problems with relying on that alone. First, hosting terms of service frequently and explicitly disclaim any guarantee that those backups will be available or restorable when you need them; hosts commonly frame their own backups as a courtesy, not a service-level commitment, precisely because backup systems can and do fail. Second, a host-side backup is still stored within that host's infrastructure, which means a large-scale failure or incident at the host level can take your backup down along with your live site.
That risk isn't theoretical. In 2016, UK hosting provider 123-reg accidentally deleted a batch of customer websites during a server migration, a widely reported incident that affected customers who had no separate backup of their own and had assumed their hosting arrangement covered them. The customers who had kept an independent, off-site copy of their site were able to restore; the ones relying solely on the host were not.
What actually needs to be backed up (people usually miss half of this)
A WordPress site is really two separate things that both need saving: your files and your database. It's common for people to back up one and forget the other, then discover the gap only during a real recovery attempt.
- The database holds your actual written content: posts, pages, comments, and site settings. This is usually the smaller of the two in file size but the most catastrophic to lose, since it's the part that can't be recreated from scratch.
- The wp-content folder holds your themes, plugins, and, critically, your uploads folder, which contains every image and media file you've ever added. This is often the largest part of a backup by file size, and it's the part people most often forget when they only set up database backups and assume that covers "everything."
- Your core WordPress files matter least on their own, since they can always be freshly redownloaded from WordPress.org identically; there's little value in backing these up specifically, beyond what's already captured in a full-site backup tool.
The step almost everyone skips: testing a restore
This is the part of backup planning that separates a real disaster-recovery plan from a false sense of security, and it's the step that gets skipped constantly, because it takes real effort and nothing appears to be wrong in the meantime. A backup file existing is not the same as a backup file working. Site owners have documented losing usable data specifically because a backup they trusted turned out to be corrupted, incomplete, or simply failed partway through the restoration process, discovered only in the middle of an actual emergency, which is the worst possible time to learn your safety net has a hole in it.
The fix is straightforward, even if it's tedious: periodically restore your backup to a staging site or a local environment, not your live site, just to confirm the file is genuinely usable and contains what you expect. Doing this once when you first set up your backup system, and then roughly every few months afterward, catches problems while they're an inconvenience rather than a crisis.
A reasonable backup schedule for most sites
- Database: daily, or even more frequently for a site with constant new content like an active blog, forum, or store with regular orders
- Full site (files plus database): at least weekly, and always immediately before any major update to WordPress core, your theme, or a significant plugin
- Retention: keep more than just the single most recent backup. If a problem goes unnoticed for a few days (a subtle hack, a slow-developing plugin conflict), your most recent backup might already contain the problem; having a few backups back gives you a genuinely clean point to restore to
What this doesn't mean: the honest nuance
None of this requires an expensive service or a complicated setup to get meaningfully protected. A well-configured free backup plugin connected to a separate cloud storage account (a service like Dropbox or Google Drive, kept genuinely separate from your hosting account) covers the automated and off-site requirements for the vast majority of small sites at no cost beyond a few minutes of initial setup. The tested-restore requirement is the one that actually takes ongoing discipline, and it's also the one that's most commonly skipped entirely, which is exactly why it's worth treating as non-negotiable rather than optional.
It's also worth being honest that a backup plan isn't a substitute for the other practices covered elsewhere in this series. A perfect backup doesn't prevent your site from being hacked in the first place, and restoring an old backup after a security incident without also patching whatever let the attacker in the first time just resets the clock until the same vulnerability is exploited again. Backups are your last line of defense, not your only one.
Frequently asked questions
Is my web host's automatic backup actually enough on its own?
For most sites, not fully. It can be a useful additional layer, but relying on it exclusively means trusting a system whose terms of service often explicitly disclaim any guarantee of availability, and one that's stored within the same infrastructure that could fail alongside your live site. Treat host backups as a bonus layer, not your primary plan.
How often should I actually back up a small, low-traffic blog?
Even a small, infrequently updated site benefits from at least a weekly full backup and a daily database backup if you publish comments or new posts regularly. The cost of running an automated backup is essentially zero once it's set up; the cost of losing months or years of content because you assumed a small site "probably doesn't need it" is much higher.
What happens if my backup itself gets compromised along with my site during a hack?
This is exactly why off-site storage matters so much: a backup stored on the same server as a compromised site can be corrupted or deleted along with everything else, and in rare cases a sophisticated attacker can specifically target backup files they find on the same server. A genuinely off-site backup, stored in a separate account entirely, isn't affected by whatever happens to your hosting account or server.
Should I always back up manually before every single plugin or theme update, even with automated backups already running?
It's a reasonable extra habit, especially before a major update (a new WordPress version, a significant plugin update, or switching themes), since it gives you an immediate, known-good restore point right before the specific change most likely to cause a problem, rather than relying on your most recent scheduled backup, which might be a day or more old.
A solid backup plan is what makes every other piece of maintenance in this series lower-stakes: you can experiment with a new plugin, test a theme change, or recover from a hack without treating every change as irreversible. From here, the series shifts from strategy to specific tools, starting with one of the most consequential choices you'll make for how your site actually looks: the next post walks through the strongest free WordPress themes available right now, sorted by what kind of site you're actually building.
No comments yet — be the first to share your thoughts.