A backup you have never restored is a guess, not a safety net. The hard truth about WordPress is that the defaults most people rely on, a nightly host snapshot or a free plugin writing zip files into wp-content, fail in exactly the scenarios you bought them for. When a host suspends your account, when a drive in the data center dies, or when ransomware encrypts the whole machine, a backup sitting on that same machine dies with it. A strategy that survives disasters is built around two questions and one old rule, and once you frame it that way the right tooling becomes obvious.

Start with RPO and RTO, not with a plugin

Before choosing software, decide how much pain you can tolerate. Two numbers define this.

RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time. It dictates how often you back up. A brochure site that changes monthly can lose 24 hours of data without anyone noticing. A WooCommerce store that takes orders every few minutes cannot, because every order placed between last night's backup and this morning's crash is gone, with the customer charged and no record of what they bought.
RTO (Recovery Time Objective) is how long you can be down before the outage actually costs you. It dictates the format and location of your backups. If you need to be live in 30 minutes, you cannot wait 48 hours for a host support ticket, and you cannot restore from a proprietary archive that only works if its original plugin is installed and licensed.

A personal blog might happily run RPO 24h / RTO a few hours. A revenue store needs RPO measured in minutes and RTO under an hour. Those are wildly different setups, and pretending one plugin configuration fits both is how people end up with backups that technically exist and practically fail.

The 3-2-1 rule, and why WordPress defaults break it

The backup discipline that predates WordPress and still governs it is 3-2-1: keep 3 copies of your data, on 2 different media or locations, with 1 copy off-site. The live site is copy one. A backup on the same server is copy two but on the same medium, so it does not count toward the "2 locations" goal. The off-site copy is the one that actually saves you, and it is the one almost every default omits.

Look honestly at the common setups against this rule:

Host snapshots (Kinsta, WP Engine, SiteGround, Cloudways) are convenient and often automatic, but they live with the same vendor as your site. If the host has an outage, a billing dispute, or suspends your account, your snapshots are inside the locked door. Necessary, not sufficient.
UpdraftPlus on the free tier writes backups into your hosting account by default. Until you connect a remote destination, every copy shares the fate of the server. Configuring remote storage is one screen, and skipping it is the single most common backup mistake on WordPress.
Manual zip-and-download satisfies off-site storage but has no schedule, no retention, and no verification. It works exactly until the week you forget.

The modern extension is 3-2-1-1-0: one of those copies should be immutable or offline (so ransomware or a compromised admin account cannot delete it), and you should be able to confirm 0 errors through actual verification, not a green checkmark.

Where the off-site copy should live

The off-site target matters less than the fact that it exists, but cost and reliability differ. Backblaze B2 is the value pick for backup storage and is roughly a quarter the price of comparable Amazon S3 standard storage, which adds up when you are keeping a year of monthly archives. Amazon S3 is the choice when you want lifecycle rules and object-lock immutability. Google Drive and Dropbox are fine for small sites and are the easiest to authorize, but their consumer quotas fill quietly, and a backup destination that silently stops accepting uploads is worse than none because it lulls you. Whatever you pick, turn on storage-side versioning or object lock so a single deletion cannot wipe the history.

Frequency: nightly is wrong for transactional sites

Most plugins default to a daily full backup. For content sites that is reasonable. For anything transactional it quietly violates your RPO. The answer is incremental and real-time backups, where each change is captured continuously rather than in a once-a-day batch.

This is where tool choice stops being interchangeable:

Jetpack VaultPress Backup and BlogVault both store off-site by default and offer real-time backups, capturing every order and comment as it happens. For WooCommerce this is the category to be in, not a nightly full.
UpdraftPlus (Premium) and Solid Backups (formerly BackupBuddy) handle incremental backups well and give you flexible scheduling and remote destinations.
Duplicator is built for migration and full-site packaging rather than continuous protection, so treat it as a cloning and pre-update tool, not your primary disaster plan.

A practical content-site cadence: daily backups kept 7 days, weekly kept 8 weeks, monthly kept 12 months. The grandfather-father-son retention matters because some damage is discovered late. A plugin update that subtly corrupts a few hundred posts may go unnoticed for three weeks, and a 7-day retention will have already overwritten the last clean copy by the time you find it. Storage for a year of monthlies is trivially cheap against the cost of not having them.

Database consistency: the failure nobody sees coming

A WordPress database dumped while writes are in flight can capture a half-finished transaction, restoring to a state where a post exists but its taxonomy relationships or post-meta are broken. The fix at the database level is to dump InnoDB tables with mysqldump --single-transaction, which takes a consistent snapshot without locking the whole site. Reputable plugins handle this acceptably for typical sites; high-volume stores benefit from real-time backup tools or dedicated approaches like Percona XtraBackup. Scheduling full backups in a low-traffic window further reduces the odds of catching a write mid-flight.

A backup is a restore you have not tested yet

This is the part nearly every guide underweights, and it is the part that decides outcomes. Backup success and restore success are different events. A checksum confirms the file is not corrupt; it says nothing about whether the archive will actually rebuild a working site. The only honest verification is a test restore into a staging environment, something most managed hosts (and tools like WP Staging or Local) make a one-click affair.

Run a real restore on a schedule, monthly is a sensible default, and watch for the failure modes that only appear at restore time: a remote-storage quota that silently stopped accepting uploads months ago, an archive truncated because the site exceeded the plugin's default chunk size, hardcoded URLs that break a restore onto a different domain, or a database dump that turns out to be inconsistent. Each of these passes "the backup ran" and fails "the backup is usable."

So the question that measures your strategy is not how many backups you have or how often they run. It is this: have you successfully restored a full working copy of this site in the last 90 days? If the answer is no, you do not have a backup strategy yet, you have an untested assumption, and disasters are precisely the moment untested assumptions reveal themselves. Set the RPO and RTO, satisfy 3-2-1 with a real off-site and immutable copy, match backup frequency to how transactional the site is, and then prove it works by restoring it on purpose, on a calendar, before something forces you to do it for real.

WordPress Backup Strategies That Actually Survive Disasters