How to Back Up a WordPress Site Properly

The rule that matters: a backup you have never restored is a guess. Everything below is about making restores boring — the same copy in two places, tested at least once, with a documented procedure you can follow while stressed.

What a complete backup contains

Files without a database restore a site with no content. A database without files restores content with no images. Both, or it is not a backup.

Safe to exclude: wp-content/cache, backup archives created by other plugins, and large log files.

Method 1: a backup plugin

The practical default for most sites.

1. Install one backup plugin — never two running schedules against the same site.
2. Configure database and files together.
3. Send copies to remote storage: object storage, Dropbox, Google Drive or an email-free destination with enough space.
4. Set the schedule to match your change rate — daily for active sites, weekly for static ones.
5. Set retention deliberately: enough history to catch a problem discovered late, not so much that storage fills.
6. Turn on failure notifications, and make sure they go to an address you read.

The comparison of options is in the best WordPress backup plugins.

Method 2: manual backup

Useful before a risky change, and the fallback when the admin is unreachable.

Files — download over SFTP, or compress on the server first:

tar -czf site-files-$(date +%F).tar.gz wp-content wp-config.php .htaccess

Database — from phpMyAdmin, select the database, choose Export, use the Quick method and SQL format. Or from the command line:

mysqldump -u USER -p DATABASE > db-$(date +%F).sql
# Or, with WP-CLI, which reads credentials from wp-config.php:
wp db export db-$(date +%F).sql

Move both files off the server. A backup sitting in the web root is not a backup — and if it is reachable by URL, it is a data leak.

Method 3: host snapshots

Most hosts take daily snapshots. Use them, but understand the limits: they usually restore the whole account, they are stored with the account, and retention is often short. Treat them as the fast path for "I broke the site an hour ago", not as your only copy.

Where copies should live

Follow a simple version of the 3-2-1 rule: three copies, on two kinds of storage, one of them off-site. In practice:

• the host's snapshot (fast recovery);
• an automated plugin backup to cloud storage (independent of the host);
• an occasional manual copy on a machine you control (independent of everything).

Encrypt or restrict access to whatever holds the database. It contains user records, and on a store it contains customer details.

Test the restore

Once, deliberately, before you need it:

1. Create a staging site or a local install.
2. Restore the most recent backup into it.
3. Log in, load ten pages, check images, run a search, submit a form.
4. Compare post counts and user counts against production.
5. Write down every step you took and how long it took.

Common failures discovered at this stage: the dump excluded a table, uploads were never included, the archive is corrupt, or nobody knows the storage credentials. All much better found on a Tuesday than during an outage.

Back up before risky changes

Take a fresh copy before:

• a major WordPress, theme or plugin update — the practice in updating plugins safely;
• a PHP version change, per what can break;
• a theme switch, per how to change a WordPress theme;
• a migration to a new host, per how to migrate a WordPress site;
• any database cleanup or repair.

Keep backups working

Backups fail quietly. Check every month that:

• the last run succeeded and its file size looks normal;
• storage has room, and old copies are actually being pruned;
• the schedule still runs — a disabled wp-cron stops plugin schedules, see speeding up the admin for how to replace it with a system cron;
• notifications still reach a monitored address.

A shrinking backup file usually means the database dump is failing while the file copy succeeds. That is the failure mode most likely to go unnoticed until it matters.