A WordPress backup only really protects you if it follows the 3-2-1 rule: 3 copies of your data, on 2 different types of storage, with at least 1 copy kept off-site, independent of your hosting. But there is an unspoken fourth element, and it’s where most sites fall down: every quarter, actually check that your site can be restored from the backup. A backup isn’t a box to tick on a to-do list, it’s a process — and a corrupted or incomplete backup is worth exactly as much as no backup at all.
Why isn’t “I’ve got a backup somewhere” good enough?
Because trouble isn’t an exceptional event, it’s part of normal operation. 58% of site crashes are caused by a poorly tested plugin update — not a hacker, just an everyday click on the “Update” button (aWh). At that point there are two scenarios: you restore yesterday’s backup in a few minutes, or you call in a specialist.
Without a usable backup, recovery with expert help can be expensive — often many times what an automated backup system costs to run for a whole year. (Source: aWh)
And that’s the better outcome, because money can solve it. According to aWh’s summary, 60% of cyber security incidents would result in permanent data loss without a proper backup (aWh) — no expert can conjure order data and uploaded images back out of thin air.
What is the 3-2-1 backup rule?
3-2-1 has been the tried-and-tested rule of thumb for data protection for decades, and in 2026 it is still the foundation for every business website (aWh):
• 3 copies: the live site plus at least two separate backups. • 2 types of storage: don’t keep everything on the same platform — for example, cloud storage (S3, Google Drive or similar) alongside your host’s own backup. • 1 off-site location: at least one copy should be physically away from the original server. If anything happens to the server — hardware failure, fire, a hack — the off-site copy is still there.
The logic is simple: no single event should be able to take out every copy at once. This is vital with ransomware, because attackers now deliberately target any backups they can reach and encrypt those too — and an infection like this can start with a single convincing phishing email.
According to Sophos’ 2025 survey, only 54% of organisations that recovered their encrypted data were able to do so from their backups — the lowest rate in six years — and nearly one in two of those affected ended up paying the ransom. (Source: Sophos)
If you have a good, isolated backup, most extortion attempts lose their teeth: you restore the site and don’t negotiate.
Is your hosting provider’s automatic backup enough?
Not on its own — and that isn’t the hosting providers’ fault, it’s the nature of the solution. It has three weak points (aWh):
• 1. Same location. The backup typically lives in the same infrastructure as your site. Whatever reaches the live site can reach the backup too. • 2. Overwriting. The automatic backup overwrites the previous one every day. If an infection or a fault is working away quietly, within a few days all your backups are infected. • 3. Retention period. Most plans keep backups for 7–30 days — but hidden malware can come to light weeks later, so for critical data a retention period of 30–90 days is recommended.
Here’s how the backup levels compare side by side:
| Solution | What it protects against | What it doesn’t protect against |
|---|---|---|
| Host’s automatic backup | Server failure, accidental deletion in the last few days | Same location; overwriting; short retention period; nobody has tested a restore |
| Backup plugin (e.g. UpdraftPlus) to external cloud storage | Off-site copy, your own schedule, longer retention | If the site’s engine crashes, the plugin is unreachable too; setup and testing are down to you |
| Managed 3-2-1 backup with restore testing | Multiple locations, multiple storage types, documented restores tested every quarter | The weakest point is still you: your passwords and update discipline — we covered this in our article on 2026 attack trends |
What should you back up on a WordPress site, and how often?
Two things, always together: the files (wp-config.php, uploaded images and documents, modified themes) and the database (posts, users and, for an online shop, orders). If either is missing, the restore fails: according to one analysis, 32% of failed restores are caused by inconsistency between the files and the database (aWh). You can safely leave out the cache and tmp folders.
How often depends on how much data loss your business can tolerate:
• Brochure site, rarely updated: a weekly backup may be enough. • Active blog, company website: daily backups. • Online shop: daily file backups plus hourly database backups — orders, stock levels and customer accounts change constantly, and a single lost hour can wipe out dozens of transactions (aWh). • Before every update: a separate manual backup, without exception. This is your last line of defence if the update goes wrong.
Where? Encrypted, in a location physically separate from your hosting: cloud storage or a remote server — never only on the server your site runs on.
How to test that your backup can actually be restored
This is the most important section of the article, because simply having a backup proves nothing. The only way to verify a successful restore is a test restore, and it’s worth doing at least once a quarter (aWh). Here’s what it looks like in practice:
• 1. Set up a test environment: a subdirectory, subdomain or local installation — don’t touch the live site. • 2. Restore the latest backup: files and database together. • 3. Check that it works: does the site load? Can you log in to the admin? Are the most recent posts there and, for an online shop, the most recent orders? • 4. Time it and note down the steps: in a real emergency, this document will be your invaluable cheat sheet.
One of our online shop clients learned the difference the hard way. After a plugin update the site crashed, and they were calm: the backup plugin had been reporting for months that the backup was complete. Only when restoring did it turn out that, due to a lack of storage space, the plugin had been creating truncated file backups for weeks, and no database backup at all — the emails about the error had been landing in the spam folder. In the end we pieced the site together from an older hosting backup, re-entering several days of order data by hand. A single quarterly test would have flagged this in advance.
A side benefit of a restore test is that you review the state of your site at the same time — if you’re not sure your live site is clean, our article on 8 tell-tale signs of a hacked website will help with a quick check.
When did you last test a restore? If the answer is “never”, let’s talk
At WPShield, managed 3-2-1 backups and a quarterly restore test are part of the maintenance plan — in other words, we don’t take the backup’s word for it that it works, we make it prove it. Request our free quick security check: we’ll look at what you have backed up, where and since when, and tell you honestly whether your site could be restored from it by tomorrow morning.
Frequently asked questions
What is the 3-2-1 backup rule?
It’s the basic rule of data protection: keep 3 copies of your data (the live site plus two backups), on 2 different types of storage, with at least 1 copy in an off-site location physically away from the original server. That way no single server failure, hack or provider outage can take out every copy at once.
How often should a WordPress site be backed up?
Match it to how often your content changes: for a rarely updated brochure site a weekly backup is enough, for an active blog daily, but for an online shop daily file backups plus hourly database backups are recommended, because orders keep coming in. Always take a separate manual backup before every update too.
Is my hosting provider’s backup enough?
Not on its own. Your host’s automatic backup is usually in the same location as your site, and older backups are overwritten after 7–30 days — if you notice a problem later, there’s nothing left to restore. It’s a good safety net, but under the 3-2-1 rule you need your own copy stored off-site alongside it.
How do I test whether my backup can be restored?
Once a quarter, restore the latest backup to a separate test environment (a subdirectory, subdomain or local machine), and check that the site loads, you can log in to the admin and the latest content is there. Only a test restore proves the backup is intact — a corrupted backup file is worth as much as no backup at all.
