Why WordPress Backups Fail on the Worst Day (and How to Build a Plan That Doesn't)

Harshit Verma — Thu, 05 Nov 2026 09:56:24 +0000

Most site owners find out whether their backups work at the exact moment they can't afford to find out. The site is down, the host's support queue is long, a client is calling, and someone opens the backup folder to discover that the newest file is from March. Or that the archive is zero bytes. Or that the database export stops halfway through a table.

None of this is rare. It happens to careful people because backups fail silently. A green tick in a dashboard says a job ran. It does not say that the job produced something you can use.

This article is about that gap. We will go through what a backup has to survive, the specific ways backups break without telling you, where copies should live, what a trustworthy backup run looks like from start to finish, and how to test your own setup without taking your site offline. The advice applies whether you run one blog or look after thirty client sites. It is written for people who already know they need backups and want to know whether theirs would hold up.

What a backup actually has to survive
Start with the disasters, because the backup plan should be designed against them and not against an imaginary tidy world.

A WordPress site is two things stuck together: a folder of files (WordPress core, themes, plugins, and the uploads folder with every image you have ever added) and a database (posts, pages, settings, users, orders, comments). Lose either and you do not have a site. The files without the database give you an empty shell with a setup screen. The database without the files gives you content with no theme, no plugins and no media.

The things that take sites down fall into a few groups.

Your own mistakes. A plugin update that conflicts with another plugin and throws a fatal error. A theme edit that leaves a stray character in a PHP file. A bulk search-and-replace in the database that changed more than you meant. These are the most common cause by far, and they are also the easiest to recover from, provided you have a recent copy from before the change.

Hacks and malware. Compromised sites often have injected code spread across dozens of files and rows in the database. Cleaning is possible but slow, and you never quite trust the result. Restoring a known-clean copy from before the infection is often faster, as long as you know when the infection started and still hold a copy from before that date. That second condition is where short retention windows hurt.

Hosting problems. Accounts get suspended, servers fail, a hosting company has a bad week, a migration goes wrong, or a billing dispute ends with access cut off. In several of these cases, everything on that server is out of reach, including any backups stored there.

Plain bad luck. A disk fills up. A cron job deletes the wrong folder. A staff member with admin access removes something they thought was unused.

Notice what these have in common. In at least two of the four groups, the server itself is part of the problem. A backup design that depends on the server being healthy fails in exactly the cases where you need it most. Hold that thought, because it comes back in the section on where copies should live.

Five ways backups fail without telling you
Here are the failures that show up again and again in forum threads, hosting support articles and the general experience of people who maintain WordPress sites for a living. None of them needs bad luck. They are just the default outcome when nobody checks.

1. The backup lives on the same server as the site
This is the most common design flaw and the easiest to miss, because the backup does exist. Many backup plugins save their archives into a folder inside wp-content by default. Some hosts keep their own snapshots on the same infrastructure as your account. If the server dies, is wiped, or the account is suspended, the site and its backups go together.

A related version: the backup is "offsite" but only to a cloud account that was set up once, using a login that has since expired. The plugin keeps running, keeps failing to upload, and keeps quietly leaving archives on the local disk instead.

2. The job times out on a large site
Many backup tools run inside WordPress, which means they run inside PHP, with PHP's limits on time and memory. A small brochure site compresses in seconds. A store with years of product images and a large database takes much longer, and a shared host may kill the process before it finishes. Some tools handle this by splitting the work into chunks and resuming, and some do it well. Others just stop. What you see in the log depends on the tool, and sometimes the answer is nothing at all.

There is also a WordPress-specific wrinkle. WordPress's built-in scheduler, WP-Cron, does not run on a real clock. It fires when someone visits the site. On a quiet site, "daily at 3am" can drift to whenever the next visitor arrives. If your visitor count is low, a scheduled backup can slip by hours or skip a day. Many hosts and developers handle this by triggering WP-Cron from a real server cron job, but it is easy to forget that the scheduler is only as reliable as the way it is called.

3. The database export is incomplete
Files are easy to check: the archive either opens or it doesn't. Database dumps are trickier. A dump is a long text file of SQL statements. If the process is interrupted, perhaps by a timeout, a full disk or a dropped connection, you can end up with a file that looks like a normal dump but ends in the middle of a statement.

The standard MySQL dump tool writes a comment line at the very end of a complete dump saying that the dump was completed, with a date. If that line is missing, the file is not whole. It is a simple, cheap check, and plenty of backup setups never perform it.

4. Retention deletes the good copy before a new one exists
Retention policies say how many days of backups to keep. Sensible ones keep a rolling window. A badly designed one can delete the oldest copy first and then try to create a new one. If the new job fails, the window shrinks by one. If it fails for a week, you can end up with nothing.

The safer order is the reverse. Create the new backup, confirm it is good, and only then prune the old ones. That way a bad night or a bad week leaves you with more copies, not fewer.

5. Nobody finds out
This is the one that turns every other failure into a disaster. A backup that fails loudly is an annoyance. A backup that fails quietly can go on for months.

Look closely at your own alerts. Do you get a message when a backup fails? Good. Do you get one when a backup does not run at all? That is a different event. A scheduler that has stopped, a site whose credentials were changed, a plugin that was deactivated during an update: in each case there is no failed job to report, just an absence. Most monitoring only reacts to events. Absences need a different check, one that asks "which sites should have run in the last day, and did each of them?"

Where copies should live
Backup advice has a rule of thumb that has stuck around for a long time: keep three copies of your data, on two different kinds of storage, with one copy somewhere else entirely. It is called the 3-2-1 rule. You do not need to follow it to the letter for a small blog, but the thinking behind it is worth borrowing.

Take it apart for a WordPress site. The live site is copy number one. A second copy on another medium, such as a download to your own computer or a snapshot at your host, covers the case where the live copy is damaged. The "somewhere else entirely" copy covers the case where the whole location is lost: the server, the data centre, or the account.

For a site that earns money, the offsite copy is the one that matters most, and it has to meet a few conditions to count.

It is independent of your hosting account. A different provider, a different login, a different billing relationship. If your host suspends your account, you should still be able to reach it.
It is written by something that does not depend on your site being alive. If the thing that creates and sends the backup lives inside WordPress, a fatal error stops it. If it runs from outside, it keeps working while the site is down.
It is not reachable by whatever compromised the site. If an attacker gets into your server and finds credentials for your backup storage lying around in a config file, they can delete your backups too. Storage credentials should be scoped to the minimum, and ideally old copies should be hard to delete from the server side.
It is encrypted and under a retention policy you chose. You should know how far back you can go.
There is a practical decision here for people who just want the problem to go away. You can assemble this yourself with a plugin, a storage bucket from a cloud provider and some patience. You can use your host's tools, understanding they sit on the same infrastructure. Or you can use a service that handles the offsite part for you. If you would rather not wire up buckets and API keys, a managed option that lets you backup your website offsite without a cloud account of your own is one route. The trade-off is a monthly cost and a dependence on one more vendor, against the time and risk of maintaining your own setup. Neither is wrong. What matters is that you have made the choice deliberately and that the copy is somewhere your host cannot touch.

What a trustworthy backup run looks like, step by step
It helps to picture what a good backup does from start to finish, because each step is a place where a poor one cuts a corner. This is the sequence worth looking for, regardless of which tool you use.

Connect and authenticate cleanly. The tool needs access to your files and your database. For a plugin, that access is built in because it runs inside WordPress. For an external service, it usually means SSH or SFTP access, with the key or password stored encrypted. A well-built external tool reads the database credentials from wp-config.php at the time of the backup, so a password change does not quietly break the job.

Capture files and the database together. The two halves should be taken close in time. If the database is dumped at 3:00 and the files at 3:40, and someone publishes a post with images in between, the copies will not match. For most blogs the mismatch is harmless. For a busy store with orders coming in, it can matter, and some owners prefer to put the site in a short maintenance state for the dump or use a consistent-snapshot option on the dump tool.

Stream, don't stage, if you can. Some tools write the whole archive to the server's own disk first and then send it elsewhere. That needs free space equal to the size of the site, and it puts a large temporary file in a place that may be backed up or scanned. Others stream the data as it is created, straight to the destination. Streaming is friendlier to hosts with tight disk quotas, which is common on shared plans.

Verify before calling it done. This is the step that separates a backup from a hope. At a minimum, check that the archive can be read end to end, that the database dump contains its completion line, and that the file sizes are not suspiciously tiny. A 40 KB archive of a site with a 2 GB uploads folder did not capture the uploads.

Store offsite, then clean up. Upload to the independent location, confirm the upload, and delete any temporary copy.

Prune only after success. As described earlier, remove old backups only after a good new one is safely stored.

Report, including absences. Send an alert when something fails, and send a regular summary that lists every site that should have run, so that a missing run stands out.

If you want to see how one provider documents this sequence, the how agentless SSH backups work page walks through connection, nightly run, verification, storage and restore in order. backupyoursite's documentation describes verification as a gate that a run must pass before it is reported as successful, which is the same principle as the list above. Whichever tool you pick, ask its vendor or read its docs for answers to these steps. If a tool cannot tell you what it verifies, assume it verifies little.

Restore drills: the only real proof
Everything so far is about producing good backups. None of it proves you can get a site back. Only a restore proves that, and most people have never done one.

A restore drill does not need to be dramatic. The goal is to find the surprises in a calm moment instead of a crisis. Here is a simple version you can do in an hour.

Pick a target that is not your live site. A staging copy, a spare subdomain, or a local environment on your own computer. Never practise on production.
Download or select a recent backup. Use the actual file from your offsite storage, not a local file you happen to have. You are testing the real path.
Restore the files and import the database. Follow your tool's restore steps exactly as you would in an emergency. Write down every place you got stuck.
Fix the URLs if needed. A site restored to a different domain will still point to the old one in the database. Know how you would change that, either with a search-and-replace tool that handles serialized data properly or with WP-CLI.
Load the site and click around. Home page, a few posts, the admin area, a form, and for stores, a test checkout. Check that images appear.
Time it. Note how long the whole thing took, from "decide to restore" to "site working".
That last number is worth having. People in operations call it the recovery time, and the other half, how much recent work you can afford to lose, is the recovery point. A site that takes a single daily backup has a recovery point of up to a day. A shop that processes orders all day may find that unacceptable and need more frequent database backups. A small brochure site that changes once a month may be fine with weekly. Decide the numbers on purpose.

Two further notes on drills. First, repeat them after major changes: a host move, a new plugin that stores data in odd places, a change of backup tool. Second, if you manage sites for others, do one drill per client site at least once, and keep a short written procedure for each. When the call comes at night, you will not remember that this one site uses a custom database prefix and a separate uploads path.

Plugin, host backup, service or manual: choosing without drama
Each approach has real strengths. Here is a fair look at where each fits.

A backup plugin is the usual starting point, and for good reasons. It is easy to set up, many are free, and you can pick your own storage destination. The weakness is the one described above: it runs inside the thing it protects. On a healthy site this is fine. On a broken site you may not be able to start WordPress to run the restore. Most plugins let you download the archive and restore it manually through your hosting panel, and you should know how to do that before you need to. Large sites can also strain the plugin's time and memory limits, so test with your real data size.

Your host's backups are convenient and often included in the price. They are worth having as an extra layer. They are rarely sufficient alone, because they sit with the host, run on the host's schedule, and are kept for the host's chosen period. Some hosts charge for restores or limit how often you can request one. Read the terms for your plan.

**A managed external service **removes the setup and puts the copy outside your hosting. It costs money and requires giving a vendor access to your server, which is a decision to make carefully: look at how they store credentials, what access they request, and whether you can revoke it easily. For agencies with many sites, the central view and the daily summary can be worth the price on their own.

Manual backups (exporting the database and downloading files yourself) still have a place before a risky change, such as a major version upgrade. As a standing plan, they fail for a human reason: people forget. Do them as an extra, not as the only layer.

The sensible answer for most serious sites is layers. For example: a plugin or service for the daily automated copy, a host snapshot as the fast-and-convenient layer, and a manual export before any big change. Two independent automated systems are better than one, as long as one of them is stored away from your hosting account.

A one-evening checklist
If you read this far and feel uneasy about your own setup, here is a list you can work through tonight. It is deliberately short.

Find out where your backups are stored right now. Open the folder or bucket and look at the newest file's date and size.
Confirm at least one copy sits outside your hosting account, under a login your host does not control.
Open the most recent database dump and check that its last lines include the completion comment from the dump tool.
Check your retention: how many days back can you go? Is that long enough to catch a problem you might not notice for two weeks?
Check that you receive an alert on failure, and find out whether you would also hear about a run that never started.
Do one restore drill to a staging site, and time it.
Write down the restore steps on one page and store that page somewhere other than the site itself.
Make sure someone besides you knows where it is.
If an item turns up a problem, you have just saved yourself a bad day.

Conclusion
Backups fail in dull, predictable ways: stored on the same server, interrupted by a timeout, cut short mid-dump, pruned before replaced, or simply not noticed. Every one of those can be designed out, and most can be checked in an evening.

The idea to keep is that a backup is not a file, it is a tested ability to bring a site back. Keep a copy somewhere your host cannot reach. Make sure something checks the archive before it is trusted. Prune only after a good copy exists. Learn about missing runs, not just failed ones. And restore into a safe place often enough that the process feels boring.

Do those things and the worst day will still be a bad day. It just will not be the day you find out you had nothing.

DEV Community: Harshit Verma

Why WordPress Backups Fail on the Worst Day (and How to Build a Plan That Doesn't)