Search for a WordPress backup plugin and you will find a wall of "best of" lists. They are all built the same way. A table of features, a row of green ticks, a winner at the top. By the fourth one you cannot remember which tool did what, and none of them has told you the thing you actually wanted to know, which is whether your site will come back when something goes wrong.
Feature lists are a poor guide because nearly every tool ticks the same boxes. Scheduled backups, cloud storage, one-click restore. Those are table stakes. What separates a tool that saves you from one that lets you down is how it behaves in a few specific situations, and those rarely appear in a table.
This guide takes a different route. Instead of comparing products first, it starts with the ways backups fail, then shows what to look for in a tool to survive each one. By the end you should be able to read any vendor's documentation, ask four or five pointed questions, and make a decision in an afternoon. I mention specific tools where it helps, and I try to be fair to all of them. I leave out prices, because they change and you should read them on the vendor's own page.
Start from failure modes, not features
A backup tool has one job: to give you back a working site on the day you need it. So the useful question is not "what can it do?" but "what could stop it doing that?" There are not many answers, and once you know them you can test for each.
The backup never ran
The schedule did not fire, or the job started and died. Nobody noticed, because nothing visibly broke. This is the most common failure by a distance, and it is usually a scheduling problem, which I cover in its own section below.
The backup ran but is incomplete
The archive exists, it has a plausible size, and it is missing something. A database dump that was cut off. An uploads folder that was skipped. A large file that exceeded a limit. This is the nastiest failure because the tool reported success.
The backup is intact but it went down with the site
Backups stored in the same hosting account vanish when the account does. This includes the case where an attacker or a bad script deletes everything in reach, and the case where the host suspends the account over a billing problem.
The backup is fine, but the restore fails
The files are all there and the restore still does not work. The restore process itself needs PHP and WordPress to be running, and the whole reason you are restoring is that they are not. Or the archive is large and the restore times out. Or the new host has a different PHP version.
The backup is fine, and so is the restore, but it is the wrong point in time
You discover a problem that started six days ago, and the oldest copy you kept is three days old. Retention was too short for the way you actually find problems.
Five failure modes. A good tool has an answer to every one of them, and a weak one has answers to two or three. Keep this list open while you read the rest.
Three ways a backup tool is built
Almost every WordPress backup product falls into one of three designs. The design explains more about how the tool will behave than any marketing page does, so it is worth being able to tell them apart.
Design one: everything inside the plugin
The plugin runs the backup using PHP inside your site, writes an archive, and then sends it to a place you choose, such as Dropbox, Google Drive, an S3 bucket or an SFTP server. UpdraftPlus is the best known example, and it is popular for good reason: a free version that works, lots of storage options, and a huge base of users who have asked every question already.
The strengths are simplicity and control. You own the storage account, you can see the archives, and nothing is locked to a vendor. The weaknesses follow from the design. The job runs under your host's PHP limits, so big sites on small plans can hit execution time or memory ceilings. It depends on WP-Cron to start. And restore goes through the same WordPress admin that may be broken or compromised.
Design two: a plugin that hands off to the vendor's cloud
Here a lightweight plugin on your site talks to a service run by the vendor. The service does much of the heavy lifting, often with incremental backups so only changed files travel, and stores the result on the vendor's own infrastructure. BlogVault and Jetpack Backup both work along these lines, with different feature sets around them. BlogVault is known for staging and migration tools aimed at people managing many sites. Jetpack Backup comes from Automattic and sits alongside the rest of the Jetpack suite.
The strengths are lower load on your server, offsite storage by default, and a dashboard you did not have to build. The trade is that you depend on the vendor and on a plugin being present and healthy in WordPress. If the site is down at the WordPress level, you can often still restore from the vendor's side, which is a real advantage over design one, but you should confirm that rather than assume it.
Design three: no plugin at all
A service connects to the server from outside, usually over SSH or SFTP, reads the files, dumps the database, and stores the result elsewhere. Nothing is installed in WordPress. backupyoursite's documentation describes this agentless approach, and a handful of other services work the same way, along with hand-rolled scripts that do it on a schedule.
The strengths are that the backup does not run inside PHP at all, so execution limits and memory limits do not apply, and the schedule is set by the service rather than by site traffic. The weaknesses are that you need SSH or similar access from your host, which some budget shared plans restrict, and you have to hand a third party the credentials to reach your server, which is a trust decision to make carefully. Some vendors also offer a plugin for hosts without SSH, so check whether yours does.
None of these is the right answer for everybody. A single blog on cheap hosting is well served by design one. A person looking after many client sites may prefer design two for the dashboard or design three for the independence. What matters is picking on purpose, with the failure modes in mind.
Check how the schedule actually runs
This is the single most useful technical question you can ask, and most comparison posts skip it.
WordPress has a built-in task scheduler called WP-Cron. Despite the name it is not a real cron job. It does not run on a clock. It runs when somebody visits a page: each request checks whether any scheduled tasks are due and, if so, starts them. On a busy site that works well enough. On a site that gets a handful of visits a day, a task due at 2 a.m. may not run until the first visitor arrives in the morning, and if that visitor arrives at a moment when the server is already stretched, the task may fail.
Any plugin that relies on WP-Cron inherits those behaviours. That is not a flaw in the plugin so much as a property of the platform, and it is the reason a popular complaint about backup plugins is "it just stopped running and I did not notice".
The two fixes
If you stay with a plugin-based tool, you can make WP-Cron reliable. Define DISABLE_WP_CRON as true in wp-config.php to stop the on-page-load behaviour, and then have the server's real cron call the WordPress cron runner every few minutes, for example with wp cron event run --due-now through WP-CLI, or by requesting wp-cron.php on a timer. This turns an unreliable scheduler into a reliable one with about ten minutes of work, and it is worth doing whatever backup tool you pick, since other scheduled tasks on the site benefit too.
The other fix is to use a tool whose schedule lives outside WordPress entirely. A service that triggers the job from its own servers does not care how many people visited your site last night.
What to ask
Find out what actually starts the backup. If the documentation says it uses WP-Cron, that tells you what to do next. If it says the schedule is run by the vendor's service, ask what happens when the site cannot be reached at the scheduled time: does it retry, and does it tell you?
Who owns the storage, and where does it sit
The next question is about the copy itself. Where does it end up, and who controls the place?
Your own storage account
With many plugins, the backup goes to an account you set up and pay for yourself. The upside is that the data is yours and sits in a place any tool can read. The downside is that you are now responsible for that account. Tokens expire. A free drive fills up. A password gets changed. When that happens the backup job may keep running locally while the upload quietly fails, and a lot of "my backups stopped" stories come down to exactly this.
The vendor's storage
With a managed service, storage is part of the package and somebody else keeps an eye on it. That removes a whole category of silent failure. The trade is dependency. You should know what format the backups are in, whether you can download a full archive and open it without the vendor's software, and what happens to your stored copies if you stop paying or the company closes. Reputable vendors answer these plainly in their documentation.
Same server, different folder
Whatever tool you pick, check that it does not default to saving archives in the same hosting account as the site. It is the easiest default for a plugin to ship with, because it needs no setup, and it is the one that offers the least protection. A copy that cannot survive losing the host is a convenience, not a backup.
Do you also need the host's backups?
Most hosts run their own backups, and it is sensible to keep them as a second layer. Treat them as a bonus rather than the plan. Their retention can be short, their restore process may be handled by a support ticket, and in some cases they only cover the files or only the database. Read your host's documentation to see what is actually included and for how long. Then build your own copy in a separate place, so you are not relying on one provider for both the site and its insurance.
Pricing models and the many-site problem
If you only have one site, price is easy: pick the tier that covers it. Things get more interesting when you look after several, because the plans that look similar from a distance can behave very differently as the number of sites grows.
The calculation to do is simple. Take the plan's price, divide by the number of sites it covers, and compare that with what you would pay for the same number of sites elsewhere. Check three things while you are there. First, does the plan bundle storage, and how much per site does that leave? Second, is billing monthly or annual only? Third, what happens once you pass the top published tier, and is the next step a listed price or a request for a quote? A price you cannot see is hard to budget for.
One place to practise this is a breakdown of BlogVault pricing set against per-site costs. It shows the per-site division across several site counts, which is the habit worth copying, though the comparison is written by one of the two vendors, so verify any figure against the vendor's own live page before relying on it.
A few smaller points deserve a line each. Free tiers are usually single-site, so a free plugin that works for one personal blog does not scale into an agency workflow without a paid add-on. Some products charge separately for the features that matter most for restore, such as staging, real-time backup or longer retention, so compare like with like. And annual-only billing is a bigger commitment than it looks if you are not sure you will keep the client.
Comparing the well-known plugins on the things that matter
With the failure modes in mind, it becomes easier to look at the best known names without getting lost. I will not rank them. Each is a reasonable choice for somebody. Here is what to check for each.
UpdraftPlus
The question is whether your site fits inside its constraints. It runs inside WordPress, so test it on your host with your real site size. Check that the destination you pick is something you will monitor. Look at how it handles a large database and whether it splits archives into parts, which helps with upload limits. Confirm what the free version covers and what needs the premium one, because features such as incremental backups and some storage destinations sit in the paid tier.
Jetpack Backup
The question is whether you want the rest of Jetpack. It is a sensible pick if you already use the suite and want one vendor. Look at which of its backup features sit on which plan, particularly real-time versus daily, and at how restores are handled, since they go through the vendor's service. If you do not otherwise want Jetpack, check how much additional code you are putting on the site for the sake of one function.
BlogVault
The question is whether you want the staging and multi-site dashboard that come with it. It is built for people managing many sites, and the staging and migration tools are a real draw. Check how the plan structure maps to your number of sites and what retention each tier gives. Confirm that you can still restore if the site itself is unreachable.
An agentless service
The question is whether your host allows what it needs. Check for SSH access, and if you do not have it, whether there is a fallback. Think about how comfortable you are giving a vendor the ability to log in to the server, and ask how credentials are stored. Ask what verification the service performs before it calls a backup good.
If you want one more reference, there is a longer write-up comparing BlogVault vs UpdraftPlus and Jetpack, with an agentless option added as a fourth. As with the pricing breakdown, it comes from a vendor, so treat it as one input and run your own test.
That table is a summary of general design tendencies, not a verdict on any product. Individual tools vary, and vendors change features. Use it to decide what to check, not what to buy.
A restore test you can run in an afternoon
Whichever tool you shortlist, do not decide on the strength of reading alone. A short test teaches you more than any comparison, and it exposes the failure modes from the start of this article.
Step 1: set up a real test
Choose a real site, not an empty install. A throwaway site with three pages will pass every test and tell you nothing. Pick one with a decent number of uploads, a few plugins, and a database with some content in it. If you can, use a copy of a client site on a staging domain.
Step 2: take a backup and look inside
Run a manual backup and download it. Open the archive. Is the uploads folder present and the right size? Open the database dump in a text editor and scroll to the end. A complete dump finishes cleanly. A truncated one stops mid-line. This takes five minutes and catches the incomplete-backup failure directly.
Step 3: restore to somewhere else
Restore to a different location: a staging site, a spare subdomain, or a local environment. Do not overwrite your live site as a test. Watch what the tool asks you to do. If there is a step where it needs WordPress already installed, note that.
Step 4: check the result properly
Log in to the admin. Open a handful of posts and pages with images. Visit the shop or a form and look for a recent entry. Check that permalinks work and that the site's URL settings are right, since moving between domains is where serialized data in the database causes trouble. If you changed the domain, use a search-and-replace that understands serialized values, for example WP-CLI's wp search-replace, rather than a raw find-and-replace on the SQL file, which can corrupt stored settings.
Step 5: time it and write it down
Note how long the whole thing took from deciding to restore until the site worked. That is your real recovery time. Repeat the test every few months and after any big change to the site, because a setup that worked at 2 GB may behave differently at 20.
Step 6: break it on purpose
If the tool offers failure alerts, test them. Revoke the storage token or change the SSH key, and see whether you get told, how quickly, and whether the message is clear. A tool that fails loudly is much better than one that fails quietly.
Retention, frequency and what you can live with
Two settings decide how much damage a bad day can do: how often you back up and how long you keep copies. The tool you pick needs to let you set both in a way that suits the site, and many people leave them on defaults without ever thinking about it.
Frequency sets how much recent work you can lose. A daily backup means that in the worst case you lose up to a day of changes. For a brochure site that is nothing. For a store taking orders around the clock, a day of orders is a lot, and you may want more frequent database backups, or a real-time option, with the files backed up less often. Files and database do not have to share a schedule, since uploads change slowly and the database changes constantly. Ask whether the tool lets you split them.
Retention sets how far back you can reach. The right figure depends on how fast you tend to notice problems. If you check the site daily and hear about issues from customers within hours, a week may be fine. If problems can sit for a while before anyone spots them, which is typical of hacked sites and of content changes made by several people, thirty days is a safer floor. A mix of recent daily copies and a few older weekly ones covers both cases without piling up storage.
Before you choose, work out what each tool does when it hits its limit. Some delete the oldest copies. Some stop and report an error. Some quietly skip. You want the first or second, loudly.
A short checklist to take to any vendor page
Here is everything above boiled down to a list you can run through in about fifteen minutes per tool. If a documentation page does not answer a question, send the vendor an email. How they reply is a useful signal.
Schedule: What starts the backup, and what happens if it cannot run?
Completeness: Does it include the database and all of wp-content? Are any folders or large files skipped by default?
Verification: Does it check the backup after taking it, and how?
Location: Is the copy kept away from the hosting account? Who owns the storage?
Retention: How many copies, how long, and what happens at the limit?
Restore: Can I restore when WordPress is broken? Can I restore a single file or table? How long does a large site take?
Alerts: Who is told when something fails, and how quickly?
Exit: Can I download an archive in a standard format? What happens to my backups if I cancel?
Cost per site: What is the price divided by site count, and what is the next step after the largest published tier?
Score each tool honestly, run the restore test on the top two, and pick the one that did best on your own site. Do not worry if your choice is not the one at the top of anyone's list. The list was not written for your site.
Conclusion
Choosing a backup tool is easier once you stop comparing features and start comparing failure modes. Ask what starts the backup, whether the copy is complete, where it lives, whether the restore works when the site does not, and how far back you can go. Those five questions sort most products quickly, and they cut through the marketing.
The three designs, plugin-only, plugin with vendor cloud, and agentless, each have a place. The right one depends on your host, the number of sites you manage, and how much of the plumbing you want to own. If you can only do one thing after reading this, make it the restore test. An afternoon spent restoring a real site to a staging copy will tell you more about a tool than a dozen articles, including this one.
Top comments (0)