WordPress Backup: How Often, Where To — and How to Tell It Works

Almost every website has a backup plugin. Far fewer have a backup that holds up in an emergency. The difference isn't the tool but three decisions you make once and then forget: how often, where to, and how you can tell it will hold.

The only number that matters: how much can you afford to lose?

Backup frequency doesn't follow gut feeling but a single question: how much work can be lost without it hurting? A blog with one post a week loses nothing with daily backups. A store with forty orders a day can lose up to forty orders with daily backups.

Files change less often than the database — images, themes, and plugins stay the same for days. That's why it pays to schedule the two separately: the database often, the files rarely.

Where to: the 3-2-1 rule, briefly explained

Three copies, on two different media, one of them off-site. Translated to a WordPress site, that means: the live data, an archive on the server, an archive somewhere else.

The third point is where things usually go wrong. An archive sitting in the same wp-content/uploads as the website won't survive a disk failure, a deleted account, or an attacker covering their tracks.

Your hosting provider's backup is good, but it isn't a second location. If the provider goes down, both go down together. It counts as one copy, not two.

How long: retention isn't a storage space issue

If you keep seven days, you'll notice damage that happened eight days ago too late. And that's exactly the common case: a database gets corrupted or malicious code is slipped in, and nobody notices until weeks later.

A workable rotation: the last seven days, plus four weekly and three monthly versions. That costs little extra space and covers the case where you need to go back further than you thought.

Encryption — and where the key is kept

An archive contains the entire database: user accounts, orders, email addresses, comments. If it sits unencrypted with a storage provider, it's exactly as confidential as that provider.

AES-256 is the common standard, and the question isn't “whether,” but where the key is kept. Next to the archive, it's useless. Kakapo Backup encrypts with your key and doesn't store it alongside the archive — which means you have to keep it separately. A password manager is enough.

How to tell it will hold up

A backup that has never been restored is a hope. There are two checks, and you need both:

• The technical one: does the archive's checksum still match? That catches everything that was damaged along the way — before you need it.
• The real one: can the site be restored from it? That catches everything else, and on the day it matters, that's all that counts.

1. Create a staging copy — never practice on the live site.
2. Restore the most recent archive there.
3. Open the home page, a subpage, the backend, and, if there is one, the cart.
4. Check a handful of database entries: the latest post, the latest order, a user.
5. Write down how long it took. That number is your real downtime.

Once a quarter is enough. Set yourself a reminder — otherwise the test never gets done, because it's never urgent.

The special case that happens most often

Most “emergencies” aren't a server outage but an update that broke something. That doesn't call for a full restore, but for a way back for that one specific plugin — and ideally a backup that's created automatically before every update.

So check your tool: does it create a restore point on its own before updates? And are those restore points retained differently from regular runs? A way back that the retention limit clears away after three days isn't a way back.

Frequently asked questions