Backups That Won’t Save You: The Classic Mistakes of WordPress Backup Strategy
The sentence we’ve learned to distrust
Almost every site we take over has backups running. Something produces files on a schedule, and the files are there. What nobody can usually tell us is when a restore from those files was last performed, how long it took, or whether it produced a working site.
Backing up is the easy part, and it’s the part that gets the attention. Restoring is the part that decides whether any of it mattered, and it tends to go untested until the morning the site is down and someone is losing money by the hour. A job configured eighteen months ago then has to work first time.
The six we keep finding
The backup sits on the same server as the site. By a wide margin the most common one, because it’s the default in most hosting panels and costs nothing extra. It covers the failure you’re least likely to have, which is deleting a file by accident. It does not cover a dead disk, a compromised hosting account, a suspended plan or ransomware, and each of those takes the site and the archive together.
Nobody has ever run a restore. We have opened archives that were half-written because the cron job timed out, archives with no database in them, and archives of a directory that stopped being the web root during a migration two years earlier. All of them looked fine from the outside: a file of a plausible size, dated last night.
The schedule is a plugin default rather than a decision. Daily at 3 a.m. is reasonable for a brochure site and careless for a shop taking orders overnight. What should set the frequency is how many hours of data the business can afford to lose, and that is worth answering before touching the settings rather than after.
Files without the database, or the other way round. A WordPress site is both, and the two have to come from the same moment. We see the split most often where two different tools each cover half the job, and a restore then hands you a database full of references to uploads that aren’t there.
Retention is one. A single copy, overwritten every night. Then something gets into the site, and because a modern infection is built to stay quiet, nobody notices for weeks. By the time anyone does, the only copy you have is a copy of the infected site. Depth of history is what turns a backup from an undo button into a way out of a break-in.
The backup storage uses the site’s own credentials. If the key that runs WordPress can also delete the backups, then whoever takes over WordPress can delete the backups. Attackers look for this deliberately, because a victim with no history left is a victim who pays.
What a working setup looks like
None of the fixes are difficult, which is part of why they keep getting postponed.
Copies leave the server, to storage that can’t be reached with the site’s own credentials. Files and database together, from the same moment, at a frequency somebody chose on purpose. Enough history to reach back past an infection that went unnoticed for a month; thirty days is a sensible floor, and a compliance requirement may push it higher.
Then the step almost everyone skips. Take last night’s archive, restore it onto a staging server, log in, click through the site, check that images load and recent orders are present. Time it, because that number is your real recovery time and it is usually a multiple of what people assume. Repeat every few months, and after any move between hosts.
Why it comes up so often
Sites rarely go down for exotic reasons. An update collides with a plugin, someone gets into wp-admin, a migration goes wrong. Any of those is an hour of work when there is a backup you trust behind you, and several days of reconstruction when there isn’t.
The setup takes an afternoon, once. It is the single item we most often find missing on sites that are otherwise looked after well.
