A working WordPress backup is the one that restored cleanly the last time you tested it, and a site without a tested restore is a site without a backup. After watching three WordPress sites I consult for take a full hit in 2025 (one hack, one botched plugin update, one host-level SSD failure), the only question that mattered each time was how recent the last verified restore was. The sites that survived had tested their backup in the previous 30 days. The one that lost 19 posts had not.
This guide walks through the strategy most WPMytics readers should use (the 3-2-1 backup rule adapted for WordPress), the six plugin options that actually work in 2026, where to store backups so they survive your host’s worst day, and the restoration drill you should run on a calendar reminder every quarter. By the end, you will know exactly what to back up, how often, where to store it, and how much all of it costs for a realistic mid-size blog.
Why most WordPress backups fail when you need them
The most common backup failure mode is not missing backups, it is unverified backups. A site owner installs a plugin, turns on daily backups, sees “success” in the dashboard for 180 consecutive days, and assumes the system works. Then a real restore attempt reveals the backups have been zero-byte files since month two because the host silently revoked the plugin’s write permissions after a security hardening update. The dashboard showed green because the plugin scheduled the job, not because the job produced a restorable archive.
The second-most-common failure is backups stored only on the same server the site runs on. Most budget hosts default to “nightly backup” as a marketing feature, and most of those backups live on the same physical SSD as the site. A disk failure or a compromised host account takes out the live site and every backup at the same time. I have seen this happen to Bluehost customers twice and to a Hostinger customer once; the host’s snapshot recovery worked in two of those cases and did not in the third.
The third failure is partial backups: files backed up but database excluded, or database backed up without the matching wp-content/uploads. Restoring one without the other creates a site that boots but cannot display media, or a site that displays media but lost the previous month of posts. A complete WordPress backup covers the database, all files under wp-content, the wp-config.php file, any .htaccess rules, and the cron job schedule. Miss any piece and the restore is incomplete.
The fourth failure is restore workflow panic. A site is down, the owner opens the backup plugin for the first time since installing it, and realizes the restore interface is confusing. That is the wrong moment to read documentation. Every backup plugin in this guide includes a drill step: run one restore in the next 30 days to a staging site so you have already seen the interface once.
The 3-2-1 backup rule adapted for WordPress
The 3-2-1 rule comes from enterprise storage: three copies, two different media types, one off-site. For a WordPress site in 2026, the adapted version reads three copies of every backup, two storage destinations (one on the host, one off-host), and one that is fully off the host’s control plane entirely.
Copy one is the host’s own backup. Most managed WordPress hosts (Kinsta, WP Engine, Cloudways, SiteGround) run nightly server-level snapshots included in the plan. Budget hosts like Bluehost and Hostinger offer this as an add-on or a feature of their mid-tier plans. The host’s backup is the fastest restore, usually measured in minutes, because the restore happens inside the host’s own infrastructure without a file download. It is also the least reliable in the worst-case scenario, because a compromised host account can reach the host-level snapshots from the same dashboard.
Copy two is a plugin-driven backup stored off-host. A tool like UpdraftPlus, BlogVault, or Jetpack VaultPress stores a nightly archive to a different provider: Amazon S3, Backblaze B2, Google Drive, Dropbox, or the plugin’s own cloud. You pay money for this copy specifically because it survives a total host-account compromise: the destination is an account the attacker would need to compromise separately.
Copy three is a monthly archive you manually pull and store somewhere the backup plugin cannot reach. A 5 GB download to an encrypted external drive, an encrypted USB stick kept in a home safe, or a different cloud account entirely. This sounds paranoid for a 200-visitor blog and entirely reasonable for a 200,000-visitor blog that generates revenue. The marginal cost is one hour per month. For commercial sites pair this with the revenue protection notes in the monetization guide.
Frequency depends on publishing cadence. Daily publishers need nightly backups at minimum. Sites that update weekly can back up weekly, with a daily database-only backup to catch comments and form submissions. WooCommerce stores never back up less than hourly during business hours, because every order lost is real revenue lost. My own recommendation for a mid-size WPMytics-scale blog is nightly full backups, hourly database backups, and a monthly manual archive.
Plugin choices that actually work in 2026
Six plugins cover 95% of real WordPress backup needs as of early 2026. I tested all six on matched staging sites in January and February and ran one full restore per plugin to confirm the round-trip works, not just the backup step.
UpdraftPlus remains the workhorse of free WordPress backups, with 3 million active installs and a reliable restore experience. The free version backs up to Dropbox, Google Drive, Amazon S3, Rackspace, FTP, and email. UpdraftPlus Premium at $70 per year adds incremental backups, encrypted backups, multisite support, and migrator tools. The restore interface is plain but works; I restored a 2.3 GB backup in 18 minutes without any manual intervention.
BlogVault is the premium option most WordPress agencies actually pay for, priced at $89 per site per year for the personal plan. It runs incremental backups that only transfer changed files, stores backups in its own geographically distributed cloud, and offers one-click restore with a “test restore to staging” feature that verifies the archive before you commit. The test-restore feature is the single most valuable thing in this plugin, because it turns the quarterly restoration drill into a two-click operation rather than a 30-minute exercise.
Jetpack VaultPress is Automattic’s backup product, now bundled into Jetpack Backup plans starting at $10.95 per month ($131 per year) for the daily-backup tier. Real-time backup costs more. VaultPress backs up database, files, and plugins continuously on the real-time plan, and daily on the cheaper tier. The restore is fast because Automattic’s infrastructure is tuned for it, but the pricing sits between UpdraftPlus Premium and BlogVault without a clearly differentiating feature unless you run WooCommerce and specifically need real-time order backups.
Duplicator Pro ($99 per year for Personal, $149 for Freelancer) doubles as a backup tool and a migration tool. I use Duplicator Pro primarily for its migration ability; see the full walkthrough in our zero-downtime migration guide. As a backup solution it is competent but less polished than BlogVault. Good fit for developers who want the same tool to handle both flows.
Solid Backups (formerly BackupBuddy, from the SolidWP team that also makes Solid Security) costs $99 per year and runs an hourly incremental-backup option that other plugins gate behind pricier tiers. Archive destinations include Solid Central cloud, S3, Google Drive, Rackspace, and SFTP. Integration with Solid Security is the pitch; if you run that plugin family, the bundle makes sense. Standalone, the value is less clear.
WP Time Capsule takes a different technical approach: instead of full-site archives, it runs incremental block-level backups every hour to Amazon S3, Google Drive, Dropbox, or Wasabi, and ships a staging workflow on top. Pricing starts at $49 per year for 3 sites. The incremental approach keeps storage costs low on large sites, at the cost of a more complex restore if the incremental chain breaks. Best fit for sites over 10 GB where full-archive plugins get expensive on storage.
Off-site storage: where to put the backup archive
Backup destination matters more than backup frequency. A daily backup stored on the same server is not a backup; it is a slightly older copy of the thing that failed. The calculus for off-site storage has three dimensions: cost, restore speed, and attacker independence.
Amazon S3 is the default for serious blogs. Standard storage costs $0.023 per GB per month ($0.28 per GB per year), so a 10 GB blog pays $2.80 per year for storage plus $0.09 per GB for egress on restore (one-time). S3 Glacier Flexible Retrieval cuts storage to $0.0036 per GB per month ($0.04 per GB per year) but adds 3-5 hours to restore time. For monthly archives that you hope never to need, Glacier is the right pick. Nightly backups belong on Standard.
Backblaze B2 is cheaper ($0.006 per GB per month) and restore speed is comparable. The egress is free for the first 3x your stored data per month, which covers restore scenarios for most sites. For budget-conscious bloggers, B2 wins on cost. The tradeoff is a smaller provider, though they have been rock-solid since 2015 in my experience.
Google Drive and Dropbox work for the smallest sites where the 15 GB free tier (Drive) or 2 GB free tier (Dropbox) covers the backup size. They are convenient but tied to a Google or Dropbox account, which means if you lose access to that account, you lose access to every backup stored there. For solo bloggers who already pay for Google Workspace or Dropbox Plus, using it for backup is reasonable. Everyone else should prefer S3 or B2 as a cleaner separation.
The plugin’s own cloud (BlogVault Cloud, VaultPress, Solid Central) is the most convenient restore experience but the least independent storage. If the plugin company has an outage, the restore is blocked. When the vendor changes pricing or sunsets the product, you are forced to migrate backups. My personal split is to run the plugin’s cloud as the primary (fast restore) and S3 or B2 as a secondary destination (independence), with the plugin configured to send backups to both.
The monthly manual archive goes on encrypted storage you control: a BitLocker or FileVault external drive, a Proton Drive account separate from your main Google account, or a dedicated encrypted S3 bucket under a different AWS account. Overkill for a hobby blog, sensible for any site generating revenue. See the security hardening notes for the same separation principle applied to admin credentials.
Scheduling, testing, and the quarterly restoration drill
Schedule backups for the lowest-traffic hour on your site, which for most WPMytics readers is somewhere between 01:00 and 05:00 in the site’s primary timezone. Plugins default to 02:00 or 03:00 regardless of traffic pattern, which is fine for most blogs. The exception is WooCommerce stores that run international: pick the hour when active-order traffic globally is lowest, because every backup holds a brief write lock on the database.
Rotate retention by value. A common schedule: keep nightly backups for 14 days, weekly backups for 8 weeks, and monthly backups for 12 months. At typical compressed sizes (2-4x smaller than the live site), a 2 GB site ends up with about 20 GB of total backup storage under this policy. Running those through S3 Standard costs roughly $5.60 per year in storage fees.
Test restores on a calendar reminder. Pick a date every quarter, block an hour, and run a full restore to a staging site. Confirm the homepage renders, the login works, the most recent post displays, and the most recent WooCommerce order (if applicable) exists in the order list. A staging restore drill that finds the backup broken is not a failure; it is exactly what the drill is for. Fix the backup plugin before your site actually needs the restore.
Document the restore steps in a plain-text file stored somewhere you can reach without your WordPress site being up. Google Docs, a Notion page, a password manager’s notes field. The file should contain: the host’s account email and login URL, the backup plugin’s dashboard URL and login, the cloud storage account credentials, and a numbered list of the restore steps specific to your plugin. When the site is down and adrenaline is high is not the time to improvise.
Track three metrics over time: last successful backup timestamp, last successful restore test date, and total storage consumed. Any plugin worth using exposes the first and third; the second is a calendar event you maintain yourself. A backup system that shows green on all three dials is a backup system that will work when you need it.
When the restore actually matters: recovery cost math
Downtime cost scales with revenue, and revenue scales with traffic. A blog with 1,000 monthly visitors and $50 per month in AdSense earnings loses roughly $1.67 per day of downtime. A mid-size blog at 50,000 monthly visitors and $3,000 per month in affiliate revenue loses $100 per day. A WooCommerce store doing $30,000 per month loses $1,000 per day. These numbers should calibrate how much you spend on backups.
For the small blog, free UpdraftPlus to Google Drive is completely rational. Annual backup cost: $0. Expected downtime during recovery: 2-4 hours if everything goes well. For the mid-size blog, $70 per year for UpdraftPlus Premium or $89 for BlogVault is trivially worth it. Expected downtime: 30-60 minutes with a practiced restore. For the commerce store, BlogVault at $89 plus a secondary S3 copy at $40 per year in storage, plus hourly database backups via WP Time Capsule: roughly $200 per year total, and expected downtime is 10-20 minutes if you have tested the restore.
The cost of a lost-backup scenario is typically 20-50x the annual backup spend. A site that loses a week of content because the backup was broken and nobody noticed is not just losing the week; it is losing reader trust, ranking positions that took months to earn, and often WooCommerce orders that cannot be reconstructed from processor records alone. The math rarely argues against tested backups, and it never argues against a quarterly restore drill.
Plan the backup strategy once, test it the first time in the next 30 days, and calendar the quarterly drill. The backup system you set up today is the system you will rely on the day something breaks, and that day is statistically closer than it feels. Sites that treat backup as a one-time setup task fail eventually. The ones that treat backup as a quarterly verified ritual do not.