How to Back Up and Restore WordPress

Introduction

A WordPress backup needs to include both files and the database. The files hold WordPress, plugins, themes, images, documents, wp-config.php, .htaccess, and any custom code. The database holds posts, pages, users, settings, comments, menus, and orders if there’s a store.

Downloading only wp-content or exporting just the database doesn’t always let you restore the full site. At miHosting we run regular backups of your hosting (see how to back up your hosting), but keeping your own WordPress backups too gives you more control over the exact restore point.

Before creating a backup

Check the available space, avoid generating the backup inside the public folder if it contains sensitive data, note the URL, PHP version, and WordPress version, and if the site receives orders or sign-ups, do it at a controlled time. A backup is only useful if it can be downloaded, opened, and restored.

What a complete backup should include

At minimum: wp-admin/, wp-content/, wp-includes/, wp-config.php, index.php, and .htaccess, plus any extra files at the root. For the database, export every table in the install (the usual prefix is wp_, but it can differ). Document separately the DNS, SSL certificate, cron tasks, PHP version and settings, panel redirects, and email services, since these aren’t always included in a WordPress backup.

Method 1: backup from your hosting’s backup system

DirectAdmin or cPanel may offer a backup tool that includes the domain’s files, databases, email accounts, DNS, and certificates. Always download a copy off the server — if the only copy is on the same account and that account becomes unreachable, you won’t be able to use it.

Method 2: copy files from the file manager

Log in to the file manager, open WordPress’s main folder, select every file (including hidden ones), compress them into a .zip or .tar.gz, and download the archive. Check that .htaccess is included. On large sites, compressing from the panel can run out of time or space — use SSH or your hosting’s backup system instead.

Method 3: copy files via FTP or SFTP

Connect to the server, turn on hidden file visibility, download the entire WordPress folder, and check for any failed transfers. SFTP encrypts the connection and is preferable when it’s available.

Method 4: export the database with phpMyAdmin

Open phpMyAdmin, select the database in DB_NAME, click Export, choose Quick and SQL format, and download the file. For large databases, use the custom export with gzip compression. Check that every table was included.

Method 5: backup via SSH and WP-CLI

From the WordPress folder (see managing WordPress with WP-CLI):

wp db export /safe/path/database.sql

tar -czf /safe/path/wordpress-files.tar.gz \
  --exclude='wp-content/cache' \
  --exclude='*.log' \
  .

gzip /safe/path/database.sql

Store the backups in a non-public path with restricted permissions.

Recommended frequency

It depends on how much content you can afford to lose: a corporate site with few changes might need only a weekly backup and one before updates; an active blog, daily or several times a week; a store or membership site, several times a day or incremental backups. Always take an immediate manual backup before migrating, updating PHP, or installing new code.

A useful approach is the 3-2-1 strategy: 3 copies of the data, on 2 different types of storage, with 1 copy off the main server. Encrypt backups if they contain personal or sensitive data.

How to verify a backup

Before trusting it, check that the file isn’t zero bytes, open the archive and review its structure, confirm wp-config.php exists and wp-content/uploads has images, open the SQL file with a suitable editor and confirm it has tables, and periodically restore it in a test environment. A restore test is the most reliable check.

How to restore WordPress step by step

Before restoring

Determine which date you need, whether you’ll restore files, the database, or both, what recent content will be lost, whether the backup belongs to the same domain and server, and whether the database credentials have changed. Back up the current state, even if it’s broken — it may contain recent orders or files that aren’t in the older backup.

Step 1: prepare the destination folder

If you’re restoring over the current install, rename or move the existing folder and create a clean one. Don’t permanently delete the previous state until you’ve confirmed the restore works.

Step 2: restore the files

Upload the .zip or .tar.gz and extract it into the correct folder, checking there isn’t an unnecessary extra folder (e.g. everything inside wordpress/). Over SSH: tar -xzf wordpress-files.tar.gz -C /destination/path.

Step 3: create or empty the database

For a complete restore, it’s best to import into an empty database — create a new database and user, or empty the current tables after saving a backup. If you change the name, user, password, or server, update wp-config.php.

Step 4: import the database

With phpMyAdmin, select the database, click Import, choose the .sql or .sql.gz file, and keep the correct character set. With WP-CLI: wp db import backup.sql (or gunzip backup.sql.gz first if it’s compressed). If the file exceeds the upload limit, use SSH or ask for help.

Step 5: review wp-config.php

Confirm DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, and that $table_prefix matches the imported tables (see database connection error in WordPress if something fails).

Step 6: fix the URL if the domain changed

First update the options (wp option update home '...' and siteurl), then run a safe replacement with wp search-replace, always testing with --dry-run first. See how to change the WordPress URL for the full procedure.

Step 7: check permissions and finish the checks

Check that ownership and permissions are correct (don’t use 777), and check the homepage and pages, /wp-admin, images, plugins and theme, forms, permalinks, email, the SSL certificate, cron tasks, and the store. Go to Settings > Permalinks and save to regenerate the rules if you see 404s.

Restoring only the database or only files

Restoring only the database is useful when content was deleted or a setting changed data, but keep in mind an old database can wipe out recent orders or changes. Restoring only files can help if a plugin or theme got damaged or images are missing — don’t restore an old wp-config.php if the current credentials are different.

Common issues

Error connecting to the database

Check credentials, the user, permissions, DB_HOST, and the prefix.

500 error after restoring

Check PHP, .htaccess, plugins, permissions, and logs (see WordPress 500 error and white screen).

Images are missing

The backup didn’t include wp-content/uploads, the paths are wrong, or the permissions don’t allow reading the files.

The import stops partway through

The file may exceed PHP or MySQL limits. Use the console or split the import with suitable tools.

Frequently asked questions

Is a backup plugin enough?

It can be, if it includes both files and the database, stores copies off the server, and you’ve tested the restore.

Do my hosting’s backups replace my own?

You shouldn’t rely on a single layer. Keep at least one backup under your own control.

Should I store backups inside public_html?

No. They could be downloaded if they become accessible. Use a private path or external storage.

Can I restore a backup from a different PHP version?

Yes, but plugins, themes, or code may not be compatible. Test and check for errors.

Conclusion

A complete WordPress backup includes files and a database created around the same time. Keep several versions, store at least one off the server, and periodically test the restore.

If your site handles orders, bookings, or critical data, combining your own backups with miHosting’s automatic ones reduces risk, but you still need to know the restore point and confirm the backups are usable.