In November 2018, a developer sent an email to all parties about an industrial business that ran its entire operation through a custom intranet system holding its customer records, order history and supplier relationships in a single database. The hosting provider had been running what everyone understood to be nightly backups. When a restore was requested to investigate a data discrepancy, the backup failed. The MySQL databases were not included. A configuration change in March had broken the database component, and the nightly status emails had never flagged it. For eight months the backup saved everything except the database.
The developer’s email read, in part: “Obviously inadequate backups is everyone’s worst nightmare. For [the owner] not to have a reliable DR could mean he would lose his business entirely as everything his business knows and operates on resided in the intranet system.”
What followed that email was a conversation about implementing backup verification — a process where the backup would be restored into a test environment and validated by script on a regular basis, quoted as a separate line item. No data had actually been lost: the live database was intact, and only the backup was missing it.
Automated, Frequent, Off-Site, Tested
Automated. Scheduled on the server by cron or the host’s own scheduler, so it runs without WordPress loading and without a person logging in to start it.
Frequent. Daily backups are the common default. For any site processing bookings, form submissions, orders, or updated content — a 24-hour backup gap means up to 24 hours of data loss in a worst-case restore. For an e-commerce site processing twenty orders per day, that is twenty orders that may not exist in the recovered database. For a booking system, it is appointments that were confirmed but cannot be retrieved.
Off-site. If UpdraftPlus, All-in-One Migration or Duplicator stores its archives on the same server as the WordPress installation, those archives live in the same failure domain, and can recover a deleted file or a broken plugin update but little more. If the server hardware fails, both the site and the backup go down together. If ransomware encrypts the disk, it encrypts the backup folder too.
On our platform, site files are snapshotted every six hours and each snapshot is kept for 35 days. Databases are backed up continuously and can be restored to a point in time, to within minutes, anywhere in the same 35 days. Both are stored on AWS infrastructure separate from the web server, and neither depends on WordPress running.
Tested. Backup software produces success logs. Those logs confirm that a file was written on schedule; in 2018 they confirmed it nightly for eight months while the MySQL databases were missing from it.
The client lead’s follow-up in 2018 was a specification: send a complete list of the files, folders and databases being backed up, when the backups run and where they are stored, and check it “maybe every month to ensure no changes have impacted this.”
A Restore That Worked
In April 2024, a small accommodation business in New Zealand had their site compromised. The restore happened the same day: back up the same evening, malware scans the next morning, plugin updates applied as part of remediation. The files were rolled back to the previous day’s state from a backup held off the compromised server; the database was preserved so no enquiries were lost. The client’s response, when the site came back up: “Ok that’s good.”
What a Backup Policy Actually Requires
There is an enterprise data recovery standard called the 3-2-1 rule: three copies of the data, on two different media types, with one copy stored off-site. A plugin writing archives to the web server’s own disk gives you one copy, on one medium, on-site.
For a small WordPress website, a realistic backup policy requires:
Host-level backups, not plugin-level. Backups taken at the server or snapshot level, stored on infrastructure that is separate from the web server. They cannot be accessed through the same WordPress credentials that may be part of a breach.
A retention schedule you understand. A single nightly backup with a three-day retention means that if a compromise is discovered five days after it occurred, you have no clean restore point. Thirty days of daily backups means you can roll back to a point before the infection took hold.
Six-hourly or more frequent backups for active sites. Content sites with weekly updates can tolerate a daily backup gap. Booking systems, e-commerce stores, and any site where daily transactional data matters cannot.
Documented and tested restore procedures. The 2018 specification: a written list of the files, folders and databases covered, when backups run and where they are stored, and a monthly restore into a test environment, validated by script.
Granular restore capability. The ability to restore only the database, or only the files, or only a specific directory — not just a full system restore. The April 2024 accommodation site restore worked because files could be recovered without touching the database. A full restore would have wiped out the customer enquiries from the past day.
Backups, Attack Surface and Monitoring
Truth #4 in this series covers the attack surface a WordPress server accumulates: shared credentials, leftover admin tools, abandoned installs. A web file manager left behind after a build reads the same disk as the site, so it reaches an on-server backup folder as easily as it reaches wp-config.php.
Truth #8 covers monitoring. A site with good backups and no monitoring may not discover the compromise until after the backup retention window has expired.
What to Ask Your Host
- Are backups automated, or do they require manual action?
- How often do they run — daily, six-hourly, more?
- Where are backups stored — on the same server, or separate infrastructure?
- What is the retention period — how far back can I restore?
- Have you ever tested a restore from these backups?
- Can you restore granularly — files only, database only — or only full site restores?
- What happens to my backups if the server is compromised?
A free audit of your current hosting setup — including backup policy, security configuration, and performance — is available at managedhosting.partners.
