A WordPress site without an off-site, recent and tested backup is operating on borrowed time. Sooner or later something breaks - a hack, an accidental delete, a botched plugin update, a failed disk in the host's array - and the only thing standing between you and rebuilding from scratch is a copy that lives somewhere other than the server itself.
Why this matters
Data loss in WordPress rarely has one cause. In production we see four recurring scenarios. Real intrusions, where an attacker plants a webshell and then deletes wp-content to cover their tracks. Operator error, where someone clicks Delete on what they thought was an inactive plugin and only later discovers it owned a custom post type table with two years of content. Update incompatibility, where a builder plugin pushes a release that conflicts with an old theme and leaves the site on a White Screen of Death. And provider-side hardware failure, where an SSD dies without warning in a RAID set that wasn't quite as resilient as advertised.
In every one of those scenarios the difference between two hours of downtime and a permanent loss is whether you have a copy that lives somewhere other than the affected server. A backup stored in wp-content/uploads/backups is not a backup - if the disk dies, both copies die. Even host snapshots are not enough on their own: many providers retain only seven days of snapshots, and a targeted attacker will disable snapshot retention before deleting data.
How to detect
The RankPlus scan checks whether one of the common backup plugins is installed and active: UpdraftPlus, BackWPup, BlogVault, Solid Backups, Duplicator Pro or Jetpack Backup. If none of them is active the check fails. It is worth verifying separately in your hosting control panel: many managed hosts (Kinsta, WP Engine, SiteGround) take daily server-level snapshots - that does not replace a plugin but it is a useful additional safety layer.
How to fix
- Install UpdraftPlus from the plugin directory. It is free, well maintained, simple to configure and supports almost every off-site destination.
- In the plugin's settings configure the schedule separately: Files once a day, Database twice a day or more for active sites (WooCommerce, forums, membership).
- Choose a remote destination - not a local disk. Backblaze B2 is extremely cheap (around 0.005 USD per GB), Amazon S3 is rock solid, Google Drive is convenient if you already have Workspace, Dropbox is simple but pricier per GB.
- Configure retention for at least 14 backups, ideally 30. Keeping only one backup means that if a breach happened three days ago and the latest backup already contains the malicious code, you have nowhere to roll back to.
- Run the first backup manually and verify it actually lands at the remote destination - not just "Scheduled".
- Once a month perform a test restore into a staging environment. That is the only check that proves the backup truly works.
Common mistakes
- Local-only backups: setting "Save backup to server" without uploading to the cloud. When the server dies, the backup dies with it.
- One destination: even cloud providers can lock an account. The 3-2-1 rule says three copies, two media types, one off-site.
- Never testing restore: an untested backup is worth zero. We have seen sites with two years of corrupted archives where the owner only found out when they actually needed to restore.
- Storing credentials in the DB: S3 access keys inside wp_options can be exfiltrated together with a database dump.
Verifying the fix
After configuring backups, re-run the RankPlus audit - the status should turn green. In addition, log in to the remote destination (Drive, S3, B2) and confirm the archive is there, download it and verify it opens as a valid ZIP with wp-config.php and a wp-content directory inside. UpdraftPlus exposes a Test Restore button - use it.