Most WordPress site owners have backups. Almost none of them have backups they have actually tested. The difference becomes brutally visible at the worst possible moment, which is the day they need them. This article describes a real case from a recent Sydney agency incident where the backup story almost made a difficult recovery into a near disaster, and what we changed to make sure it does not happen again.
The incident
The agency runs a portfolio of small business client sites on a single shared host. One of them, the agency’s own site, was compromised. An SEO cloaking attack had quietly dropped malicious files into the document root, mirroring real WordPress page names with attacker controlled content. The cleanup itself was straightforward once the entry point was identified. The harder part was deciding how far to roll back.
Forensic analysis suggested the attacker had been on the site for at least a few weeks before discovery. To be safe, the recovery plan called for restoring from a backup taken before the suspected entry date. The cleaner the pre incident baseline, the less chance of any subtle backdoor surviving the cleanup.
The first surprise
The backup plugin had been installed and configured at site launch, two years earlier. The plan was for daily database backups and weekly full backups, both uploaded to an offsite cloud storage account. When the agency owner went to retrieve a backup from six weeks before the incident, the answer was uncomfortable. The most recent backup in the cloud storage was from twelve months ago.
The backup plugin had been silently failing for at least the last year. The agency had no idea. The notifications about the failures had been going to an email address that was no longer monitored. Nobody had thought to check the destination storage to confirm files were actually arriving. The system had been quietly broken for far longer than the actual security incident.
The second surprise
The agency turned to the host for fallback. Many managed hosts keep their own backups independent of any plugin. In this case, the host’s backup retention was 30 days. The compromise was suspected to have started around 45 days before discovery. The host’s backups were inside the compromise window, not before it.
Any backup the host could provide had a strong chance of containing the attacker’s files. Restoring from those would simply reset the timer. There was no clean pre incident point to restore to.
The recovery path that worked
With no clean backup, the recovery had to be done file by file. The forensic snapshot of the current site was compared against a fresh WordPress core download, theme files were verified against version control where it existed, plugins were reinstalled from their official sources rather than reused from the compromised codebase, and the database was scrubbed for known malicious patterns without being rolled back.
This took several times longer than a simple restore would have. Every step had to be verified. The total cost was substantial, and several improvements on the site were lost because the most recent verifiable theme code was from a months old export rather than the live state. The cleanup worked, but the cost was significantly higher than it should have been.
The new backup arrangement
After the incident, the agency moved to a backup arrangement we use across the WordPress sites we manage. The features matter, so it is worth being specific.
Daily incremental backups of both files and database. Weekly full backups. All backups stored off site in a storage account that is not accessible from the WordPress site itself, so a compromise cannot wipe the backups along with the live site.
Retention is set so that backups remain available for at least 90 days. This gives a clean pre incident window even for slow burning compromises.
Alert notifications for failed backups go to a monitored business inbox, not a personal email. Two people receive the alerts so a single person’s holiday cannot mask a failure.
A quarterly restore test runs against a staging environment. The backup is downloaded, restored, and verified against the live site. If anything is broken, it is fixed before the next quarter.
What you can do today
If this case sounds uncomfortably familiar, here is a short list of steps you can run through this week. Each takes minutes.
Log in to whatever destination your backups go to. Confirm the most recent file is from today or yesterday. Confirm files have been arriving consistently for the last 90 days. Open the email address that should receive backup failure notifications and confirm it is still monitored.
Pick the most recent backup. Download it. Try to restore it to a staging site or a local environment. Make sure it actually works as a backup, not just as a file.
Check your host’s backup retention. Is the retention window long enough to cover a slow compromise. If not, supplement with a longer retention off site solution.
The principle
A backup is only real once you have restored it. Until then it is a guess. The cost of testing is small. The cost of finding out the hard way is large enough to threaten the recovery itself. Treat backup verification as part of your routine, not a thing you would get to one day.
Need a hand?
If your WordPress backup story has gaps, Smart Coding can audit it, set up reliable off site backups with proper retention, run a restore test to verify it works, and make sure the alerts go to people who will see them. Get in touch and we will give you a backup arrangement you can actually rely on.
