A WordPress Backup and Restore Checklist That Works

Back up both the WordPress database and the files needed to restore the site. Keep a separate copy and rehearse the restore on a test environment before relying on the backup.

What a Complete Backup Must Contain#

WordPress stores your site in two separate places, and a backup that captures only one of them is half a backup. The MySQL database holds your posts, pages, comments, site settings, and user accounts — effectively everything you would recognise as content. The file system holds wp-content/uploads with your images and documents, plus your themes, plugins, and configuration files such as wp-config.php and .htaccess. Losing the database leaves you with an empty shell; losing the files leaves you with text and no images. Confirm that whatever handles your backups explicitly includes both halves.

Apply the 3-2-1 Rule#

The 3-2-1 rule is a longstanding framing from broader data-protection practice, and it translates cleanly to websites. Keep at least three copies of your data, on two different types of storage, with at least one copy kept offsite — meaning somewhere entirely separate from your web hosting server, such as dedicated cloud storage. The reasoning is simple: if the server is compromised or its hardware fails, any backup living on that same server is likely to be lost along with everything else. An offsite copy is what turns a backup into a recovery plan.

When to Run Backups#

Backups belong on a schedule you do not have to remember. Automatic daily backups suit most sites; a busy store or a news site that changes hourly may justify more frequent snapshots. Scheduling alone is not enough, though. Take a manual backup immediately before any update to WordPress core, a theme, or a plugin — the moments surrounding updates are precisely when something is most likely to break, and a pre-update copy lets you return to a known state in minutes rather than rebuilding. Treat that pre-update backup as non-negotiable, even when the update looks trivial.

Test the Restore, Not Just the Backup#

An unverified backup is a hope, not a plan. Files can be incomplete, database dumps can be truncated, and the restore process itself often turns out to be more involved than expected. The only way to know is to rehearse: restore a backup onto a staging site or a local test environment and check that the site actually works. While you are there, note three things — whether the database restored cleanly, whether all files came across, and how long the whole process took. That last number matters during a real incident, because it tells you how long your site will be down before it is back.

Retention, Access, and Documentation#

A few practical details make the difference between a backup system and a pile of archives. Keep enough history that a problem discovered weeks later still has a clean copy to return to; if a site is compromised, the most recent backup may already contain the compromise. Store credentials for your backup storage somewhere safe and separate from your WordPress administrator account, so a site-level breach does not also take out your recovery options. Finally, write the restore steps down once, while you are calm, because whoever faces the emergency later will not be calm.

The Checklist#

• Confirmed the backup includes both the database and the files
• At least three copies, on two storage types, one fully offsite
• Automatic schedule running daily or more often as needed
• Manual backup taken before every core, theme, or plugin update
• Restore tested on staging or a local environment, with timing noted
• Restore steps written down and stored somewhere accessible offline
• Backup storage credentials kept separate from the site itself