How to Backup WordPress (and Restore It Without Breaking Your Site)

To backup WordPress properly you need two things: a copy of the site files (mainly wp-content and wp-config.php) and an export of the database. One without the other is not a backup. Keep at least one copy outside your hosting account, run backups on a schedule that matches how often your site changes, and test a restore before the day you actually need one.

What a full WordPress backup contains

WordPress keeps your site in two places: files on disk and rows in a MySQL or MariaDB database. A complete backup covers both:

• The database: posts, pages, comments, users, settings, menus, widgets, WooCommerce orders and customers, and most plugin settings. Tables usually start with the prefix wp_.

• wp-content/uploads: every image, PDF and media file you have uploaded. This is usually the largest folder and the hardest to recreate.

• wp-content/themes and wp-content/plugins: public ones can be reinstalled from wordpress.org, but child themes, custom code and premium plugins often cannot be re-downloaded quickly.

• wp-config.php: database credentials, the table prefix, security salts and any constants you added. If the prefix in wp-config.php does not match the restored tables, WordPress shows the installer as if the site were empty.

• .htaccess and other root files: rewrite rules, redirects, security headers, and verification files for Google Search Console.

Check today: open one of your existing backup archives. Some plugins skip uploads by default, and some database exports stop silently at a size limit. No uploads folder and no .sql file inside means no full backup.

Host backups, plugin backups and offsite copies

1. Host-level backups

The host copies the whole account (files, databases, often email) to separate storage on a schedule. These run outside WordPress, so they work even when WordPress is broken or hacked. The limits: the host sets retention, and the copies sit with the same provider as your site.

2. Plugin backups

A plugin exports the database, zips files and pushes the result to cloud storage on your schedule. Weak points: it needs a working WordPress, it uses PHP time and memory on the same server (large sites hit timeouts), and anyone who takes over an admin account can delete the backups with the site.

3. Offsite copies you control

A copy with a different company, in an account whose credentials the website does not hold. It saves you if the hosting account is suspended, an attacker gets full access, or someone deletes the wrong folder.

The rule that ties these together is 3-2-1: three copies of your data, on two different types of storage, with one copy offsite. For a typical WordPress site that means the live site, the host's daily backup, and a regular export to storage you own. We cover retention, snapshots and restore drills in more depth in our guide to the 3-2-1 backup strategy.

How often should you backup WordPress?

Ask how much work you can afford to lose. That answer is your backup interval. Rules of thumb by site type:

• Company or brochure site, edited monthly: daily host backups plus a manual backup before every change is enough.

• Blog or news site publishing daily: a daily database backup at minimum. Files can be daily or weekly, since uploads change less often than posts.

• WooCommerce store or membership site: the database changes with every order and signup. Daily is the floor, and busy stores back up the database every few hours, because restoring yesterday's database means losing today's orders.

• Before any risky change: core updates, major plugin updates, a theme switch, a PHP version change or a migration. Take a fresh backup right before, every time.

Retention matters as much as frequency. Malware is often noticed days later, so if you keep only three days, every copy may be infected. Keep 14 to 30 days of daily backups where storage allows, plus a monthly copy.

How to backup WordPress manually

From cPanel

1. Open File Manager, select the folder that holds the site (usually public_html), compress it to .zip or .tar.gz, and download the archive.

2. Open phpMyAdmin, select the site's database (check DB_NAME in wp-config.php if there are several), click Export, keep the Quick method and SQL format, and download the file.

3. Store both files outside the hosting account, named with the date.

cPanel's Backup page can also generate a full account backup. Delete any archive you created on the server once downloaded: a .zip left in public_html can be fetched by anyone who guesses its name, and it contains your database password.

With SSH and WP-CLI

If your plan includes SSH access, WP-CLI is faster and does not run into PHP time limits. From the WordPress folder:

cd ~/public_html
mkdir -p ~/backups
wp db export ~/backups/db-$(date +%F).sql
tar -czf ~/backups/files-$(date +%F).tar.gz -C ~ public_html

Without WP-CLI, mysqldump does the same job for the database. Replace dbuser and dbname with the values in wp-config.php:

mysqldump --single-transaction --quick -u dbuser -p dbname | gzip > ~/backups/db-$(date +%F).sql.gz

The --single-transaction option takes a consistent snapshot of InnoDB tables without locking the site while the export runs. Then copy the folder offsite, for example with rsync to a storage server you control (replace the host with your own):

rsync -avz ~/backups/ [email protected]:/srv/backups/mysite/

Run these lines from cron and you have a scheduled offsite backup that needs no plugin.

How to restore WordPress safely

Most restore disasters start with a panicked restore over the live site. Follow this order:

1. Find out what broke and when. A white screen after a plugin update usually needs that plugin disabled, not a full restore. A hack that started two weeks ago needs an older backup plus closing the hole the attacker used, or they return within days.

2. Back up the current broken state. It sounds strange, but it holds the orders, comments and form entries created since your last good backup. You may need to copy them across later.

3. Restore to staging first when you can. A staging copy lets you log in, open key pages and test checkout before visitors see anything.

4. Restore files and database from the same point in time. A new database with old plugin files, or the opposite, is a common source of errors after a restore.

5. Check wp-config.php. Database name, user, password and table prefix must match the restored database.

6. Clear every cache layer. Plugin cache, server cache and CDN. Otherwise you keep seeing the broken version and think the restore failed.

7. Verify, then go live. Test login, contact forms, checkout and a few old posts with images.

With WP-CLI, importing a database export looks like this:

wp db import ~/backups/db-2026-10-01.sql
wp cache flush

If you restore to a different address, such as a staging subdomain, change the URLs with WP-CLI instead of editing the .sql file by hand. WordPress stores some options as serialized data, and a plain text replace corrupts them. Run a dry run first, and replace example.com with your domain:

wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --dry-run
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid

The same backup-and-restore steps are the core of moving a site between hosts, which we walk through in the website migration checklist.

Test your restore before you need it

A backup you have never restored is a hope, not a plan. Once a quarter, and after any change to your backup setup:

• Restore the latest backup into a staging site or a local environment.

• Confirm the archive opens, the .sql file imports without errors, and images load.

• Time the whole process. That number is your realistic downtime if the worst happens.

• Write down the steps and where the offsite copy lives.

Backup mistakes that cost people their sites

• One copy, on the same server. If the account is lost or the files are encrypted by ransomware, the backup goes with them.

• A plugin configured years ago and never checked. Cloud storage tokens expire and the plugin fails quietly.

• Database only, or files only. You get posts without images, or images without posts.

• Forgetting email. If your mailboxes are on the same hosting account, they need their own backup plan; a WordPress backup does not include them.

What IM HOST WordPress hosting handles for you

On IM HOST managed WordPress hosting, free daily backups are included for the whole subscription, and you can restore a backup in one click instead of rebuilding by hand. WP Toolkit adds one-click staging, so you can try an update or a restore on a copy before it touches the live site. The WordPress management tools also cover plugins, themes and databases from one place, and our support engineers are available 24/7 if you are unsure which restore point to pick.

We still recommend keeping your own offsite copy too. That is the "1" in 3-2-1.

Frequently asked questions

Do I need a backup plugin if my host already makes daily backups?

Not strictly. Host backups cover most cases, including a broken WordPress. A plugin or a WP-CLI script is still useful for one reason: it gives you an offsite copy in storage you own, on a schedule you choose.

Can I restore only the database, or only one folder?

Yes. If content is wrong but files are fine, import only the database. If one plugin folder was damaged, restore just that folder. A partial restore is often safer than a full one, as long as files and database stay compatible.

Will restoring a backup delete new orders or comments?

Yes. Anything created after the backup point disappears from the restored database. That is why you back up the current state before restoring, so you can recover recent orders or entries from it.

Where should I keep offsite WordPress backups?

Any storage with a different provider and separate login: a cloud storage bucket, a backup server, or at minimum a drive you keep offline. Encrypt the archives if they leave your control, since they contain your database credentials and customer data.

If you want daily backups, one-click restore and staging without building them yourself, take a look at IM HOST WordPress hosting, from $3.99/mo. Moving from another host? Our team handles it through the free migration service.