WordPress backup best practices: offsite copies and tested restores

A backup is not a ZIP you hope is fine. It is a recent copy of files and the database stored somewhere other than the same server, that you have restored at least once. Security reduces the chance of a bad day. Backups reduce the cost of one.

Security Ninja is not a backup plugin. Pair prevention with a dedicated backup path. Hands-on habits: WordPress backup tips. Product context: backup and security plugins.

Why backups matter

• Human error (deleted content, bad deploy, wrong import)
• Plugin or theme update that breaks the site
• Hosting failure or accidental wipe
• Malware or takeover where you need a clean point in time
• Compatibility testing without gambling production

WordPress.org’s own guidance still points at multiple copies in different places. Treat that as the minimum bar, not an advanced tip.

What to include every time

1. Files: WordPress core (or a clean reinstall plan), wp-content (themes, plugins, uploads), and wp-config.php
2. Database: posts, users, options, WooCommerce orders, forms, everything in MySQL/MariaDB

Files without the database (or the reverse) are not a full site restore.

Prefer automatic jobs, keep a manual habit

Automate daily or hourly backups depending on how often the site changes. Ecommerce and membership sites usually need tighter intervals than a quiet brochure site.

Still run a manual backup before big changes: major core upgrades, theme swaps, bulk imports, DNS moves. Automation covers “I forgot.” Manual covers “I am about to touch something scary.”

Most hosts offer snapshots. Use them, but do not rely on host-only copies. If the account is compromised or the provider has a wider outage, you want an independent store.

Offsite storage is non-negotiable

Send backups to object storage or another provider you control: S3-compatible storage, Backblaze, Google Drive, Dropbox, a second host, encrypted disk offline. Same-server folders labeled backup are convenient for attackers and disappear with the disk.

Practical pattern:

• Automatic plugin or server job → offsite destination
• Host snapshot as a second lane
• Retention you can afford (for example 7 daily + 4 weekly), not infinite clutter you never test

Test the restore

Assume breach (or a bad deploy) will happen eventually. The question is whether you can recover.

At least once a quarter:

1. Restore files and database to a staging URL or local copy
2. Confirm the site loads, admins can log in, and critical flows work (forms, checkout, membership)
3. Write down the steps so the next person is not guessing at 2 a.m.

An untested backup is a theory.

Encryption and access

Encrypt backups in transit (SFTP, HTTPS to the storage API) and at rest when your tool supports it. Store encryption keys outside the site being backed up. Anyone with the backup and the key owns the data.

Limit who can download backups. A full dump includes user tables, options, and sometimes secrets. Treat it like production access.

Plugins vs host tools

Solid options exist (UpdraftPlus, BlogVault, Jetpack Backup, WPvivid, host-native jobs, and others). Pick one primary path and make it reliable. Stacking three backup plugins usually creates noise, not safety.

Do not confuse SEO or caching plugins with backup tools. And do not install “nulled” premium backup plugins; they are a common malware vector.

When comparing security plugins that also talk about backups, read backup and security plugins so expectations stay clear.

After a compromise

Restoring an infected backup without closing the hole repeats the incident. Clean or rebuild, rotate credentials, then restore to a known-good point. Start with hacked site steps and malware removal.

Keep it boring

Schedule the job, send copies offsite, keep a short retention you understand, and prove a restore on staging. That is the whole practice. For the shorter companion checklist of habits, use WordPress backup tips.