A backup is only useful if it restores. This WordPress backup and recovery checklist walks you through planning backups, storing them safely, proving they work, and restoring without making things worse. Tick items as you go; your progress is saved only in this browser. Use Print checklist to keep a copy with your recovery notes.
Never test a restore over your live site. Use a staging or local copy. A restore that goes wrong on the live site can turn a small problem into a long outage.
0 of 24 done
Print checklist Reset
1. Plan your backups Decide what to back up The database plus files: wp-content (plugins, themes, uploads), wp-config.php and .htaccess. Decide how often Match frequency to how much you could lose: weekly for quiet sites, daily or more for shops and busy sites, and always before updates or moves. Decide where copies live At least one copy away from your web server, such as cloud storage you control or your own computer. Decide how many to keep Several recent copies plus an older one, because some problems are discovered weeks later. 2. Make and store backups Schedule automatic backups Use your host’s backups and, ideally, an independent backup tool or process. Make a manual backup before risky changes Updates to complex plugins, PHP upgrades, migrations and design changes. Keep backup files out of public folders A database export contains user emails and password hashes. Move it off the server. 3. Verify that backups are usable Confirm the latest backup exists Check its date, size and that it reached off-site storage. Open the archive and check its contents The uploads folder should be there with a sensible number of files. Check the database export Compare the number of tables with your live site and confirm the export is complete. Test-restore on staging regularly Restore to a staging or local copy, never over the live site, and check logins, pages, images and forms. See how to prove a backup will restore . 4. Before you restore Find out what went wrong first If the site was hacked, a restore without fixing the way in leads to reinfection. See site redirecting to spam . Back up the current state, even if broken It preserves recent orders, comments or content, and gives you a way back if the restore fails. Choose a backup from before the problem started Check the date carefully, especially for malware, which may predate the visible symptoms. Decide the scope Full site, files only or database only. A database-only restore loses everything stored in the database since that backup. Plan for lost changes Note orders, posts, form entries and comments made after the backup date so you can re-enter them. 5. After restoring Test the site logged out and logged in Home page, key posts, forms, checkout and the dashboard. Purge every cache Page cache, CDN and optimised files, so visitors do not see the old version. Change passwords if there was a security incident WordPress users, hosting, SFTP, database and email accounts, plus the security salts. Write down what happened and what you changed It makes the next recovery faster. If a backup fails Read the backup log for the failing step Timeouts, memory limits, permission errors and storage errors are the usual causes. Check disk space and remote storage space Old backups kept on the server often fill the disk. Reconnect expired cloud storage Storage connections can expire after password or permission changes. Contact your host if nothing works Many hosts keep their own short-term backups and can help restore. Related guides
For the official overview of what to back up and how often, see the WordPress backup documentation .
