Wednesday, September 9, 2026
GrowrAI logo
All guides
Troubleshooting guide Recovery

How to Back Up a WordPress Site (and Actually Restore It)

Most WordPress backups fail on the day they are needed, not the day they are made. Here is how I set up backups that restore cleanly, using a plugin, cPanel, or the manual route, plus the restore drill nobody runs until it is too late.

GrowrAI Editorial Team Published September 9, 2026 Last reviewed September 9, 2026 13 min read Step-by-step walkthrough
Reviewed and tested by the GrowrAI team on a real WordPress install before publishing. How we test fixes
WordPress site backed up to cloud storage with database and files, and a restore arrow back to the site

What's Happening

Almost every emergency I get called into starts the same way. The site is down, the owner says there is a backup, and then we find out the backup is six months old, or it only holds files and no database, or it lives in the same hosting account that just got wiped. A backup you have never restored is a guess, not a safety net. WordPress needs two things saved together to come back to life: the files in your install, which include wp-content, your theme, plugins, uploads, and wp-config.php, and the MySQL database, which holds every post, page, user, setting, and WooCommerce order. Save one without the other and you have half a site. This guide covers the three ways I actually back sites up, the storage rules that keep a copy alive when the server does not, and the restore steps, because restoring is the part that goes wrong.

Complete Fix Checklist

  1. 1Decide what needs saving. Files and database together, every time. A files-only backup restores an empty site and a database-only backup restores content with no theme.
  2. 2Check what your host already runs. Most managed hosts keep daily automatic backups for 14 to 30 days, and cPanel hosts often keep weekly ones. Find the retention period before you pay for anything.
  3. 3Install UpdraftPlus, or your preferred backup plugin, from the official WordPress directory and open Settings > UpdraftPlus Backups.
  4. 4Set the schedule to match how often you publish. Daily files and daily database for an active shop, weekly files and daily database for a blog that changes rarely.
  5. 5Send backups off-site. Connect Google Drive, Dropbox, Amazon S3, or Backblaze so a copy exists outside the hosting account.
  6. 6Set retention to keep at least the last 7 copies, so a problem you notice a week late is still recoverable.
  7. 7Run one backup manually and download the archive to your own computer. That is your known-good copy before any big change.
  8. 8For the cPanel route, open Backup Wizard, download a Full Account Backup for archiving, or take a Home Directory download plus a database export for a working copy.
  9. 9For the manual route, download the whole public_html folder over SFTP, then open phpMyAdmin, select your database, and use Export > Quick > SQL.
  10. 10Test the restore on a staging copy, not on live. Restore the archive, load the front page, log into wp-admin, and open a post.
  11. 11Write down where the backups go and who has access. A backup nobody can find during an outage is not usable.

Quick Tips

  • Files and database must be backed up together, or the restore leaves you with half a site
  • A backup stored only on the same server disappears with the server, keep an off-site copy
  • Retention matters more than frequency, since malware and corruption are often noticed days later
  • wp-config.php and the .htaccess file are easy to miss because file managers hide dotfiles by default
  • A backup you have never restored is an assumption, run one test restore on staging every few months
  • Before a plugin, theme or PHP upgrade, take a fresh manual backup rather than trusting last night's

Frequently Asked Questions

How often should I back up my WordPress site?
Match the schedule to how fast your site changes, not to a rule you read somewhere. A shop taking orders needs the database backed up at least daily, and hourly if losing an afternoon of orders would hurt, because every order lives in the database. A blog that publishes twice a month is fine with a weekly file backup and a daily database backup, since the database is small and cheap to copy. The files change only when you update plugins, themes or core, so many sites run daily database backups and weekly file backups. The important part is the retention window. Keeping seven daily copies is far more useful than keeping one very recent copy, because problems like malware or a slow database corruption are usually noticed several days after they start.
What is the difference between a file backup and a database backup?
Files are everything on disk: WordPress core, your theme, plugins, media uploads, wp-config.php and .htaccess. The database is a MySQL store holding your posts, pages, comments, users, plugin settings, menus, widgets and WooCommerce orders. Neither is useful alone. Restore only files and you get a working WordPress install with no content, prompting you to run the famous five minute install. Restore only the database and you get all your content pointing at a theme and plugins that are not there, which usually produces a fatal error or a white screen. Every backup you keep should contain both, taken at the same time, so the content and the code that renders it actually match.
Are my host's automatic backups enough?
They are a good baseline and a bad only-plan. Host backups are convenient and usually free, but they live in the same infrastructure as your site, and the retention is often shorter than people assume, commonly 7 to 14 days on shared plans. If the account is suspended, the payment fails, or you get locked out during a dispute, the backups can be as unreachable as the site. There is also the practical issue that some hosts charge a restore fee or take hours to action the request. Use host backups as your fast rollback option, and keep an independent off-site copy through a plugin or manual download for the cases where the hosting account itself is the problem.
How do I back up WordPress manually without a plugin?
Two downloads. First the files: connect over SFTP or open your host's File Manager, and download the entire public_html folder, or whichever folder holds wp-config.php, wp-content and wp-admin. Make sure hidden files are visible so .htaccess comes with it. Second the database: open phpMyAdmin from your hosting panel, select the database named in wp-config.php on the DB_NAME line, click Export, choose Quick and SQL format, and save the .sql file next to the file archive in a dated folder. That pair is a complete backup. The manual route is slow on large media libraries, so I use it mainly for one-off snapshots before risky work rather than as a routine.
How do I restore a WordPress backup?
If you made the backup with a plugin such as UpdraftPlus and WordPress still loads, the cleanest path is to install the same plugin on the target site, upload the archive set, and use its Restore button, selecting database and files together. If WordPress does not load at all, restore manually: upload the files over SFTP so they overwrite the broken install, then in phpMyAdmin drop the existing tables and import the .sql file. After either route, log in, go to Settings > Permalinks and click Save Changes to rebuild the rewrite rules, then clear every cache layer, including your caching plugin, any object cache and Cloudflare. Check the site in a private window, since your own browser will keep serving the broken version otherwise.
Why does my restored site show the wrong URLs or a mix of old and new pages?
Because the database still holds the URLs from wherever it was backed up. When you restore to a different domain, a staging subdomain or a new host, the siteurl and home values in wp_options plus thousands of absolute URLs inside post content still point at the original address. Images break, links jump back to the old site, and logins can redirect away. Fix it with the Better Search Replace plugin, running a dry run first, replacing the old domain with the new one across all tables with serialisation handling enabled, which protects the serialised arrays that plugins store their settings in. A plain SQL find and replace corrupts those arrays, which is why the plugin route is safer.
Where should I store backups so they survive a disaster?
The rule I follow is three copies, two kinds of storage, one off-site. In practice that means the host's own automatic backup, an automated copy pushed to cloud storage such as Google Drive, Dropbox, Backblaze or S3, and a periodic manual download you keep yourself. The off-site copy is the one that matters when a server fails, an account is suspended, or a hack reaches everything inside the hosting environment. Keep the cloud account on separate credentials from your hosting login, use two factor on it, and check monthly that new archives are actually landing there, because silent authorisation failures after a token expires are the most common reason a scheduled off-site backup quietly stops working.
Can a backup restore a hacked site safely?
Only if you are certain the backup predates the compromise, and that is harder to know than it sounds. Many infections sit quietly for weeks, so a restore from last night can put the same backdoor straight back. Before restoring, work out roughly when the site changed by checking file modification dates, and pick a copy from before that point. After the restore, change every password, database, hosting, WordPress admin and SFTP, update WordPress core, all plugins and the theme immediately, and run a scan with Wordfence or your host's scanner. If your only backups are newer than the infection, treat the restore as a starting point and clean it properly rather than assuming the copy is clean.

Sources and Further Reading

More guides in this area: Recovery troubleshooting hub