A backup plugin’s green checkmark isn’t proof of anything. I wrote that same line in the VPS resource isolation piece, and it’s worth repeating here because this post used to be exactly the kind of advice that checkmark culture produces: a long list of tools, several of which no longer exist, with no mention of what actually makes a backup worth having.
Here’s what’s actually true about backing up a WordPress site.
Why Backups Actually Matter
Plugin updates break things. Hosts have outages. Accounts get hacked. Someone fat-fingers a bulk delete. None of these are exotic scenarios, they’re the normal cost of running a site for long enough, and a real backup strategy is what turns any of them from a disaster into an inconvenience.
The Two Layers a Real Backup Covers
Most people think “backup” means one thing. It’s actually two, and missing either one leaves a real gap.
Files: themes, plugins, uploads, everything sitting on disk. This is what most backup plugins handle well by default.
Database: every post, page, comment, setting, and piece of structured data WordPress relies on. This is the part that’s easy to under-cover, and it’s exactly what the mysqldump routine in the MySQL tricks post walks through directly, including the flags that matter and the InnoDB/MyISAM caveat most guides skip.
A backup that only covers files, or only covers the database, isn’t a real backup. It’s half of one.
The Plugin Layer: What’s Actually Worth Using in 2026
The old version of this post recommended tools like WP-DB-Backup, Bei Fen Backup, DBC Backup, and MyEASYBackup. None of them are still maintained, and Humyo, one of the storage services it pointed to, shut down years ago. Here’s what’s actually current:
| Plugin | Best for | Real limitation worth knowing |
|---|---|---|
| UpdraftPlus | Most sites, strong free tier | Can time out on sites over roughly 4GB, split archives and monitor the log rather than trusting the checkmark |
| Jetpack VaultPress Backup | Sites already in the Jetpack ecosystem | Runs server-side with no performance hit, but the ongoing cost adds up fast across an agency’s full site fleet |
| BlogVault | Revenue-generating sites, WooCommerce stores | No free tier, but the most dependable restores if you’re managing several sites |
| Duplicator | Migrations specifically | Not built for reliable scheduled backups, the free version can silently fail on scheduled runs past a certain size |
| BackupBuddy (Solid Backups) | Sites already in the SolidWP ecosystem | No incremental backups, a large store means a full re-upload every night |
| BackWPup | Budget-conscious, technical site owners | Free tier is genuinely generous, but restores lean more manual than the paid options above |
None of these is universally “the best.” The honest answer is the same one that applies to hosting choices generally: match the tool to what the site actually needs, not to whichever name shows up first in a listicle.
The Mistake That Breaks Most Backup Strategies
It’s not picking the wrong plugin. It’s where the backup ends up living. A backup stored on the same server as the site protects against almost nothing, if the server goes down, gets compromised, or the disk fails, the backup goes with it. Off-server storage isn’t optional, it’s the entire point.
Daily backups with at least 30 days of retention is a reasonable baseline for an active site. Weekly is the floor, not a safe default. Real-time, continuous backups only earn their cost premium when the site is the sole record of something irreplaceable, a high-volume store or a donation platform, not a brochure site that changes twice a month.
The Step Nobody Does: Testing the Restore
A backup that’s never been restored is an assumption, not a safety net. This is the same principle laid out in the VPS resource isolation post: restore the latest backup to a staging environment on a schedule, monthly at minimum, and confirm the site actually loads correctly against it. The day a backup matters for real is the wrong day to discover it’s been silently failing for months.
Questions People Ask About WordPress Backups
Is a backup plugin alone enough, or do I need anything else?
A good plugin covers most sites well, but it’s worth pairing with an independent mysqldump of the database periodically, since a plugin backup usually depends on that same plugin being available to restore it, while a raw SQL dump is portable to any MySQL server.
How often should I actually back up my site?
Daily, with at least 30 days of retention, is a reasonable baseline for an active site. Weekly is the absolute minimum, not a safe long-term choice. Real-time backups are worth the extra cost mainly for high-volume stores or sites where the data itself is irreplaceable.
Where should backups actually be stored?
Anywhere except the same server the site lives on. Storing a backup alongside the site it’s protecting defeats the purpose, since a server failure or compromise takes both down together.
Is it safe to trust a backup plugin’s success message?
Not on its own. Several plugins are known to produce silent partial backups on large sites, UpdraftPlus notably has this issue past roughly 4GB. Monitoring the actual backup log, not just the checkmark, and periodically testing a restore is the only way to know a backup genuinely works.
What’s the difference between a backup plugin and a migration tool like Duplicator?
Migration tools are optimized for moving a site once, not for reliable ongoing scheduled backups. Duplicator’s free tier in particular can silently fail on scheduled runs past a certain size. Use a dedicated backup plugin for the ongoing job and a migration tool for the one-time move.
How often should I actually test a restore, not just take a backup?
Monthly, at minimum, for anything worth genuinely protecting. Restoring the latest backup to a staging environment and confirming the site loads correctly is the only way to know the backup would actually work in a real emergency.
Conclusion
A backup strategy isn’t the plugin you installed once and forgot about. It’s the combination of covering both files and database, storing the result somewhere the site’s own failure can’t reach, and actually testing that it comes back clean before the day it has to. Everything else, which specific plugin, which specific storage provider, is a detail that changes over time. That discipline doesn’t.
