Journal / Tutorial

Tutorial

How to back up a WordPress site (and actually test the restore)

How to back up a WordPress site (and actually test the restore)

A backup nobody has ever restored from is a hope, not a plan. Here's a setup that covers both halves of the job.

What actually needs backing up

A WordPress site is really two things: the database (posts, pages, settings, comments, product orders — anything stored as text) and the files (theme, plugins, uploaded media). A complete backup needs both. Backing up only the files misses every post and setting; backing up only the database misses every uploaded image.

Pick a schedule that matches how often content changes

A daily backup makes sense for a site with an active blog, store, or membership area where losing a day of content is a real loss. A weekly backup is reasonable for a mostly-static brochure site that rarely changes. Match the schedule to your actual publishing cadence, not a default setting.

Store backups off-server

A backup saved to the same server it's protecting doesn't help if that server fails, gets compromised, or the hosting account is suspended. Point your backup plugin at external storage — cloud storage, a separate remote server, anything not physically on the same box as the live site.

The step everyone skips: test the restore

A backup file that has never been restored is an assumption, not a guarantee. At least once, actually run the restore process — ideally onto a staging site or a local environment, not the live site — and confirm the result is a working, browsable copy of your site. This is the only way to catch a corrupted archive, a missing database table, or a misconfigured backup plugin before you need it in an emergency.

Before any risky change, take a manual backup

Scheduled backups run on a timer, but a major theme update, a plugin change, or a hosting migration deserves its own fresh, manual backup taken immediately beforehand — not "whatever the last scheduled one happened to be."

The one-sentence version

Back up both the database and the files, store copies somewhere else, and prove the restore works before you actually need it.