What a WordPress Backup Plugin Cannot Save You From

In March a small store lost its disk. The host's status page described a failed array, the site answered with a database error, and support offered a platform snapshot four days old. The owner had a backup plugin. It had run nightly without a reported failure for two years. It wrote its archives to a folder inside wp-content, which lives on the filesystem that failed. The plugin had done exactly what it was configured to do, and the configuration was the disaster.

This is the ordinary shape of backup failure. Not the dramatic one where the plugin is abandoned, but the quiet one where the copy exists, is scheduled, carries a green tick, and sits on the same disk, in the same account, behind the same credential as the thing it protects. Backup software is the most over-trusted component on a WordPress site because its failures stay invisible until the day it has to have worked.

A backup is not a feature that gets installed. It is a copy of the site and its database that survives one named failure, stored where that failure cannot reach. The plugin is only the scheduling and transport layer for the copy.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. That does not change the price you pay, and it does not change what this piece recommends: the failures a plugin cannot cover are named below whether or not the plugin in question is the one being discussed.

The backup that was on the disk that died

The failure above is common because of a default. Most inexpensive hosts give a site one filesystem, and the path of least resistance for a backup plugin is a directory on it. Remote storage needs a bucket, credentials and a decision about who pays for it. The local folder needs nothing.

A copy on the same volume survives exactly one failure: somebody deleted a file, or an update broke the theme. It does not survive a disk failure, a host suspension or an account closed after a payment dispute. It does not survive encryption of the volume either, because the site's write permissions reach the backup directory. The copy inherits every permission the site has, which is the wrong property for something that exists to outlive the site.

The test is one sentence. If the host deleted the account this afternoon, where is the copy? If the answer is a path containing /home/, httpdocs or wp-content, there is no copy. If the answer is another provider's object storage, there is a copy, and it is worth less than it looks until somebody has checked that it restores.

This is where a plugin that writes off-server earns its place. Jetpack's backup and security modules keep copies on Automattic's infrastructure rather than on the site's disk, which removes the co-location failure by design rather than by configuration. That is the part that matters.

The restore point that already contained the infection

The second failure is a compromised site with a backup that is a faithful picture of the compromise. A redirect injected in June is invisible until August, because it fires for visitors arriving from search and the owner arrives from a bookmark. By August every restore point inside a seven-day retention window was taken while the redirect was live. Restoring one is re-infection with extra steps.

The infection may also live in something the backup stored perfectly well: a modified functions.php, an uploaded PHP shell in wp-content/uploads, a scheduled task in the options table that rebuilds the payload after cleanup. A backup is not a cleaner. It is a photocopier, and it copies the malware as accurately as the prose.

This is why retention length matters more than frequency, a point almost every backup comparison gets backwards. Hourly copies with seven days of history give the operator a hundred and sixty-eight chances to restore to a state that predates nothing. Daily copies with ninety days of history give one restore point from before the infection arrived, which is the only one that helps. Long retention buys reach, not granularity.

It also changes the cleaning procedure. Establish when the site was first modified, find a copy older than that, restore it, patch the vulnerability that let the attacker in, then rotate every credential the site held. Without long retention the first step is impossible, and the operator ends up cleaning a live site by hand, which works until the same shell is used a fortnight later.

The half-restore the file manager makes easy

The third failure is not a backup problem at all, which is why it keeps happening. The host's control panel ships with a file manager and a database tool. An update breaks the checkout, and the fastest visible fix is to import yesterday's database dump from that panel. The files stay as they are. The site comes up, the checkout works, and nobody notices that the database now sits a day behind the code until an order disappears or an editor's post reverts.

The mismatch is subtle at first. Options that plugins store in serialized arrays are read by code expecting a different shape, so a settings screen saves and silently discards. Cron entries duplicate. Password hashes revert to values from before the last reset, and the people who changed their passwords cannot log in. A store can take orders whose line items reference products missing from the reverted catalogue. None of this presents as a restore gone wrong. It presents as five unrelated bugs.

The same works in reverse. Restoring wp-content from a week-old archive while the database stays current brings back an old plugin version against a newer schema. The plugin's restore flow exists to prevent this: it takes the database and the files from one timestamp and puts them back together. A file manager cannot know that, and its interface makes the partial restore look easy. If a restore touches one half of the site, it is an edit rather than a restore. Name it that way.

The backup that competes with peak traffic

The fourth failure is the one the plugin makes worse while appearing to work. Most WordPress backup plugins schedule through wp-cron, which is not a scheduler. It is a function that runs when a page request arrives. On a site with quiet nights, the three-in-the-morning backup fires on the first request after that hour, which on a store can be ten in the morning, with the database dump competing for disk and PHP workers against visitors trying to buy something.

That is the mechanism behind a restore point thirty hours old. The job ran late, or it started and hit a timeout on a shared host, or it held a lock that no later run cleared. The plugin logged a notice in a dashboard nobody opens, and the last good archive is from the morning before yesterday. The site has paid peak latency for a copy worse than the host's nightly snapshot, and the person running it believes the opposite.

Backups scheduled from outside the site remove both problems, because they do not depend on a visitor to trigger them and do not compete for PHP workers. That is worth paying for on a transactional site and irrelevant on a brochure site whose host snapshots the account. Frequency hides a similar trap: a fifteen-minute interval on a busy store means a continuous read of a large database through the working day, and an archive list nobody will test. Two restore points a day is plenty for operator error. The number that matters is how far back the oldest useful copy reaches.

What a working backup strategy is made of

Strip out the products and the working version is short. Three copies, on two kinds of storage, one of them off the host and in a different account. The copy has to be complete: database and files, from the same moment, restorable as a pair. It has to be reachable when the host is not, because a copy whose only access path runs through a suspended account is decoration.

Then the parts people skip. Versioning on the destination. Object storage with versioning keeps a compromised site from syncing its encrypted files over every good copy, the failure mode of a backup written into a mounted bucket. Write-only credentials. The key a plugin stores on the site is available to anyone who gets code execution there, and a key that can delete is a key an attacker will use. An independent check. Something outside the site should confirm that last night's object exists and has a plausible size, because the plugin's green tick is the plugin grading its own homework.

And the one that cannot be bought. A restore you have performed. Once a quarter, restore into a staging copy from the off-host storage, using only the documentation a tired person would find at eleven at night. Time it. Check what breaks quietly: the homepage renders, login works, checkout completes an order, permalinks resolve, and mail sends. Then write down how long it took and how old the restore point was. A restore that has never been run is a hypothesis about a backup, and hypotheses fail on the day they are tested.

For a small site the free version of all this is genuinely enough: the host's daily snapshot for the fast rollback, a weekly database export and a copy of wp-content pushed to storage in a second account, and a note in the documentation saying who performs the restore and how. The WordPress documentation on backups covers the parts without selling anything, and the wp db export command is the whole database half of it in one line. A free plugin tier that writes to a bucket you control is also fine; the limits there are retention and destination.

Paid services add the part that is awkward to do alone: storage and retention somebody else manages, a restore from a control panel that does not require the site to be up, and a support line when the restore fails at two in the morning. Jetpack's backup service is one of those, and a reasonable pick for an operator who wants the off-host copy, the activity log and a restore button without building the bucket and lifecycle rules. It is a paid addition rather than part of the free plugin, so check the current price against a second storage account and an hour a quarter.

When a backup plugin is the wrong purchase

Three situations where the money is better spent elsewhere. The first is a site whose host already keeps off-host daily snapshots and will run the restore from support, on a site whose content changes weekly. A plugin duplicates a copy that exists, usually onto weaker storage. The second is a site in active development, where staging resets and database refreshes are routine; what the operator needs there is a local snapshot tool.

The third is the one that matters. If the failure the site is exposed to is a suspended account, a mistaken database import or a compromise that has been live for six weeks, a backup service addresses none of it. A larger plan does not extend retention past its window, stop a file manager from importing a dump, or rehearse a restore. The purchase still feels like progress because it has a price and a settings screen.

The line to write down

The decision rule is a sentence on one line: the site can be restored to a copy no older than X, in Y minutes, by Z people, from storage that is not the host. Fill in the numbers from a restore that happened, not from a settings page. If the sentence cannot be written, the backups on the site are not a measure of safety. They are a count of files.

One habit is worth more than any plan tier. When something breaks, take a copy of the broken site before fixing it. The broken state is evidence, and the restore that follows is easier to trust when there is a way back to the failure. The operators who recover well have done it before, on purpose, with the clock running.