Choosing a WordPress Backup Plugin
The differences that matter are off-site storage, incremental backups, restore reliability and whether large sites complete at all. Everything else is interface preference.
The plugin matters less than the routine. Files and database together, at least one copy off the server, and a restore you have actually performed. Any plugin that does those three reliably is the right plugin — the full routine is in how to back up a WordPress site.
The features that separate them
Remote storage. The single most important capability. A backup stored in wp-content disappears with the site. Look for direct support for the storage you already use — object storage, Dropbox, Google Drive, or the plugin's own service. Check that it deletes old archives from the remote as well as locally, or storage fills silently.
Incremental backups. Full nightly archives become impractical past a few gigabytes. Incremental backups store only the changes, which makes hourly or continuous database backups realistic for a store.
Restore, not just backup. Some plugins take excellent backups and offer no restore path beyond manual upload. If the restore process requires steps you cannot do while stressed, it is not a restore process. Test it once, deliberately.
Migration. Many backup plugins double as migration tools, handling search-and-replace and URL changes. Useful if you also move sites between hosts — see how to migrate a WordPress site.
Large-site handling. Ask how the plugin deals with a 20 GB uploads folder: chunked uploads, resumable transfers, server-side compression, or a hard failure at the PHP timeout.
Scheduling reliability. Most plugins schedule through wp-cron, which only fires when someone visits. On a quiet site, backups run late or not at all. If you disabled wp-cron for performance, per speeding up the admin, make sure a system cron replaced it.
Match the plugin to the site
| Site | What to prioritise |
|---|---|
| Small blog or brochure site | Simple scheduling, free remote storage, one-click restore |
| Business site with regular edits | Daily files, more frequent database, retention of a few weeks |
| WooCommerce store | Incremental or continuous database backups — orders arrive between runs |
| Large media library | Chunked or resumable transfers, file/database separation |
| Multiple client sites | A central dashboard and per-site alerts |
For a store, ask specifically what happens to orders placed after the last database backup. Losing an afternoon of orders is a customer-service problem as much as a technical one.
Free versus paid
Free tiers usually cover: manual and scheduled backups, one or two remote destinations, and a basic restore. Paid tiers add incremental backups, more destinations, encryption, priority support, and multi-site dashboards.
For a small site with a modest uploads folder, a free tier plus your own cloud storage is genuinely sufficient. For anything transactional, paid incremental backups are cheap next to the cost of losing a day of data.
Set it up so it keeps working
- Run one backup plugin. Two schedules against the same site produce timeouts and duplicated storage costs.
- Include the database and
wp-content; exclude cache directories and other plugins' archives. - Send every backup off-site, automatically.
- Set retention to match how late you might discover a problem — a compromise found after two weeks needs a backup older than two weeks.
- Turn on failure notifications and route them to an address you read.
- Encrypt or access-restrict the remote storage; the database contains user data.
- Confirm archives are not reachable from the web. A backup file in the web root is a data breach waiting to be scanned for.
Check it monthly
Backups fail quietly, and the failure that matters is the silent one:
- did the last run complete, and is the file size in line with previous ones?
- is old data actually being pruned from remote storage?
- does the schedule still fire?
- do notifications still arrive?
A backup file that has been shrinking usually means the database dump is failing while the file copy succeeds — a state that looks healthy in the dashboard and is useless in an emergency.
Then test a restore
Restore the most recent backup into a staging site, log in, load a dozen pages, check images, run a search, and compare post and user counts against production. Write down what you did and how long it took.
The plugin comparison stops mattering the moment you have done that once. A tested restore from a basic plugin beats an untested one from an expensive plugin, every time — including after the scenario nobody plans for, in how to fix a hacked WordPress site.
Frequently asked
- Yes, as a second copy. Host backups live on the host's infrastructure and disappear with the account; an independent copy in your own storage does not.
- One that stores only what changed since the last run. It makes frequent backups practical on large sites, where a full copy every night would be too slow and too big.
- Usually a PHP timeout, a memory limit or disk space. Large uploads directories are the common trigger, and splitting files from the database often solves it.