How to back up a WordPress site that will restore

Your hosting dashboard probably says backups are on. That sounds fine until something breaks and you have to answer three questions: what does the copy contain, where is it stored, and has anyone ever restored it? Most failed recoveries had a backup. The backup just had a problem nobody found until the day it was needed.

This guide covers making a backup you can actually use: what it has to include, three ways to make one, how often to run it, where to keep it and how to prove it works. If you already have a backup and need to use it, our guide on restoring a WordPress site from backup covers that side.

Why a WordPress backup is always two things

A full backup is the database plus the files, taken at the same moment. Leave out either half and you can’t rebuild the site.

The database stores posts, pages, comments, users, settings and most plugin data. On a store, it also holds products, orders and customers. The files are WordPress core, your theme, your plugins, the wp-content/uploads folder with every image you have uploaded, and wp-config.php. WordPress’s Advanced Administration Handbook on backups warns that downloading the WordPress folder does not include the database, because the database is stored separately. The handbook’s order is to back up the database first and then the files, and to restore the files first and then the database.

The common mix-up is Tools > Export. That screen produces an XML file of your posts and pages. It contains no theme, no plugins and no settings. WooCommerce’s backup documentation says a store’s data lives in two places, the wp-content folder and the database, and that the XML export does not include orders, products or settings. Use the export to move content around, not as a backup.

Treat every archive as sensitive. wp-config.php holds your database password and security keys, and a store’s database dump holds customer names and addresses.

Which backup method suits your site

There are three ways to do it, and many sites use two of them together.

• Host backups. You don’t have to set anything up, and you can usually restore with one click or a support ticket. Ask your host what the backups include, how long they are kept and where they are stored. They often sit in the same account as the live site.
• A backup plugin. You choose the schedule and send copies to storage you own, such as Google Drive, Dropbox or S3. It is one more piece of software to keep updated, and it can fail when the server runs out of memory, time or disk space. Our explainer on what a backup plugin does and where it fails covers the failure modes.
• A manual backup. You export the database and copy the files yourself. You get full control and no plugin limits, but it takes more skill, and nothing happens unless someone remembers to do it. It works best as a one-off copy before a risky change.

For an owner without a web team, a sensible default is to keep the host’s backups as one layer and add a plugin that sends copies off-site. Plugin choice matters less than people think. Practitioners on Reddit and wordpress.org disagree about which plugin is most reliable, and the same plugin works for one person and fails for another depending on the server. Pick one plugin, not two, and check that it works.

How to make a manual backup

You need your hosting control panel login, SFTP or file manager access, and access to phpMyAdmin or SSH. Check the database name in wp-config.php (the DB_NAME line) before you start, because exporting a staging database by mistake is easy to do.

1. Pause writes if they matter. On a store or a busy membership site, pick a quiet hour. Orders that arrive while you copy can end up in one half of the backup but not the other.
2. Export the database. In phpMyAdmin, select the database named in wp-config.php, open the Export tab and export all tables as SQL. Name the file with the site and the date and time.
3. Copy the files. Using SFTP or the host’s file manager, download the whole WordPress folder, including wp-content and wp-config.php. Turn on hidden files so you also get .htaccess. Check that the transfer finished and didn’t just stop partway.
4. Write down the environment. Note the WordPress, PHP and database versions. Restoring an old backup onto a newer PHP version is a known way for restores to fail.
5. Move the copy off the server. Put the SQL file and the file archive together in storage outside your hosting account, encrypted if it holds customer data.

With SSH access, the same backup is two commands, run from the WordPress folder:

wp db export ~/backup-$(date +%F).sql
tar -czf ~/files-$(date +%F).tar.gz .

Then copy both files somewhere other than that server. Before you rely on the backup, open the SQL file and check that the tables you expect are there, including the plugin tables, and that the archive size makes sense for your site.

How to set up a plugin backup that you can trust

Installing the plugin is the easy part. What makes it work is the setup and a habit of checking it.

• Include everything. Back up the database, plugins, themes, uploads and other wp-content folders. Leaving out uploads makes the archive smaller, but the backup is no longer complete.
• Set a remote destination. A copy that stays in the plugin’s folder on your server is not off-site.
• Turn on email reports. Then actually read them.
• Read the log after the first run. In a 2026 wordpress.org thread, an UpdraftPlus user’s log showed errors and no database archive, yet the run ended as succeeded and no failure email was sent. Other people in the thread questioned the cause. Either way, the status label was not enough to go on.
• Check the remote storage directly. In another thread, a remote upload failed, the local copies kept building up, and the server filled until the site went down. Open the Drive or S3 folder now and then and check that new files keep arriving.

How often should you back up?

Back up often enough that you never lose more work than you could stand to lose. WordPress’s handbook suggests weekly backups for small sites with little activity and daily backups for busy ones. Neither is a rule. A brochure site edited once a month is fine with weekly backups. A blog publishing every day needs daily backups. A store taking orders all day needs database backups more often than daily, and Reddit commenters suggest every few hours.

Files usually change less than the database, so a common pattern is to back up the database daily and the files weekly. Separately from the schedule, take a fresh backup before every plugin, theme or core update, before a migration and before any developer starts work on the site.

Where should backup copies live?

Keep at least one copy outside your hosting account, in storage only you control. A backup in the same account as the site goes down with it: if the account is suspended, if someone steals the login, or if the host has an outage, you lose both. Practitioners call this a “3-2-1 style” setup: the live site, the host’s backup and one independent copy.

Keep enough old copies to go back past a problem you didn’t spot right away. A hack often starts days before anyone sees it, and the newest backup may already include it. Our guide on what to do when your site is hacked explains why to restore only a backup you know is clean, and only after the way in has been closed.

How do you know the backup will actually restore?

Restore it somewhere that isn’t the live site. A host staging copy or a local install with LocalWP both work. Do it once now and then on a regular schedule. Some practitioners do it monthly. Restore the files, import the database, then check the pages, images, forms and logins, and count posts or products against the live site. A homepage that loads can still hide missing tables.

A staging copy is a working site and can do real things. The Make WordPress Hosting handbook on staging warns that a clone can be indexed as duplicate content, can send emails to customers, and can run scheduled tasks that call payment or subscription services. Put a password on the copy, stop or catch outgoing email, switch payments to sandbox mode and turn off cron. If you push from staging back to live, check Settings > Reading on the live site afterwards. WordPress’s Reading settings documentation explains that “Discourage search engines” adds a noindex tag, so if that setting comes across from staging, search engines get the same instruction for your live site.

What is different on a WooCommerce store?

Restoring an older database takes the whole store back to that moment, and every order placed since then disappears. One store owner on r/woocommerce rolled back to fix a payments problem and lost several days of orders. Restoring the site doesn’t bring back the business records. You would have to match up the missing orders against your payment provider by hand.

When an update breaks something, roll back the one plugin or theme that caused it and leave the database as it is. Use a partial restore if your tool offers one. Test updates on staging before they reach checkout. Never push a staging database over a live store, because the Make WordPress Hosting handbook notes that this overwrites orders, comments and users created since the copy was made.

When to stop and get help

Stop and ask for help if a restore freezes partway through, if a backup is too big for your host’s upload limit, if the site shows “There has been a critical error on this website” after a restore, or if you suspect the backup itself is infected. Running the same browser restore again rarely works unless something has changed, such as higher PHP limits or more free disk space. If a former developer or host ran the site, ask them for a backup before you rebuild anything. They often have one.

If a backup before every update is the step you keep skipping, SiteSelf can take on routine WordPress updates and maintenance on request through chat. Before each change it says what is about to change and whether it can be undone. You still need your own off-site backup. A WordPress care plan should say who is responsible for that.

Frequently asked questions

Does WordPress back up my site automatically?

Self-hosted WordPress doesn’t back itself up. Backups come from your host or from a plugin you install. On WordPress.com, whether you get automatic backups depends on your plan.

Are my host’s backups enough?

Usually not on their own. Ask what they include, how long they are kept and how a restore works. Then keep one more copy outside the hosting account so a suspension or a stolen login can’t take away both the site and its backups.

Do I need the files if I have the database?

Yes. The database brings your text and settings back, but not the images, theme or plugin code needed to display them. A full restore needs both halves, taken at the same time.

Will restoring a backup undo recent changes?

Yes. Anything stored in the database goes back to the moment of the backup, including posts, users, settings and orders. That is why a partial or code-only rollback is safer when only a plugin broke.

Should one site run two backup plugins?

Usually not. Two plugins double the load on the server and the chance of hitting its limits, and you end up with two restore processes to learn. One plugin with an off-site destination, plus the host’s backups, covers most sites.

Who is responsible for backups, me or my developer?

Whoever the contract names. If it names nobody, assume it’s you. Write down who backs up, how often, where the copies go and who pays for a restore.