BackWPup vs. Kakapo Backup: Jobs or Proof?

BackWPup works with jobs: you define what gets backed up, where it goes, and when it runs — as many as you like, combined very freely. Kakapo Backup starts from the result: one archive, one proof, one retention rule. Two workable ways of thinking about the same task.

The short answer

BackWPup is widely used, free to start with, and very flexible in how jobs are tailored — down to pure database dumps or check runs without an archive. Restore and some destinations are part of the paid tier.

Kakapo Backup offers less assembly and more assurance: SHA-256 for every archive, AES-256 with your key, an optional GPG signature, a WORM lock against later changes, and a restore point before every update.

Where the two differ

The question that decides the choice

Do you want to build backups or prove backups? If you need many different setups — a nightly database dump, a weekly full backup, a monthly export to another destination — freely configurable jobs will get you there faster.

If, on the other hand, you need to prove that an archive is unchanged, want encryption, and have to be able to show after an incident what happened and when, you need the other direction. You rarely get both in one tool, because they're opposing design decisions.

With any free backup plugin, first check whether RESTORE is part of the free feature set. A backup you can only restore with an extra tier is an unpleasant surprise on the day it matters.

When BackWPup is the better choice

• You need many differently tailored jobs
• You want to start for free and decide later
• You back up a single site with no obligation to provide proof

When Kakapo Backup is the better choice

• You need to be able to prove that an archive is unchanged
• You want archives encrypted, with your key
• You want an automatic way back before every update
• You look after multiple sites under one license

Where the archives belong

The most important decision isn't about the plugin but about the destination. A backup stored on the same server as the website won't survive a disk failure, won't survive a deleted account, and certainly won't survive encryption by malware — in that case it was never a backup, just a copy.

• At least one destination outside the server the site runs on.
• Separate credentials: anyone who takes over the website shouldn't also be able to delete the archives with them.
• Clear retention: seven daily, four weekly, and twelve monthly versions are more than enough for most sites.
• A destination you can reach yourself — without needing access to your hosting provider, in case that's exactly where the problem is.

This applies equally to both plugins. The difference comes after that: whether it can still be proven at the destination that an archive is unchanged, and whether someone with access to the storage can read its contents.

Switching in six steps

1. Run a full backup with the old plugin and download it — that's your way back.
2. Install the new plugin and enter the destination, but don't turn on the schedule yet.
3. Run one backup manually and check whether the file arrived at the destination and has a plausible size.
4. Restore this archive to a staging copy. Without this step, all you know is that a file exists.
5. Turn on the schedule in the new plugin and turn off the one in the old plugin.
6. Keep the old plugin installed for two weeks, but without a schedule. After that, it can go.

Two backup plugins with active schedules don't mean double the safety but double the load: both compress the same files, often at the same hour of the night, and on small hosting plans that makes the server hit its time limit.

Frequently asked questions