# How to Back Up and Restore WordPress

- Link: https://offshorehosting.pk/how-to-back-up-and-restore-wordpress/
- Published: 2026-10-25T10:17:00+00:00
- Author: admin

# How to Back Up and Restore WordPress

A WordPress site can be lost in minutes — a bad update, a hacked plugin, a server
failure, a mistaken deletion — and rebuilt only if a good backup exists. Yet most
site owners discover their backup was incomplete, outdated or stored on the same
server that failed, exactly when they need it most.

This guide covers what a complete WordPress backup contains, how to create one, 
where to store it, and — most importantly — how to restore it and verify the restore
works before disaster strikes.

## What a Complete Backup Contains

A WordPress site is two things, and a backup must include both:

 1. **The files.** Everything under the site’s root directory: WordPress core, themes,
    plugins, and the `wp-content/uploads` folder with all your media. The configuration
    file `wp-config.php` is also part of this, since it holds the database credentials.
 2. **The database.** All posts, pages, comments, users, settings and plugin data live
    in MySQL or MariaDB. Without the database, the files are an empty shell.

A backup that contains only one of the two is not a backup. This is the most common
mistake, and it is usually made by people who relied on a file-only backup tool 
or a database-only export and never checked.

## How Often to Back Up

Frequency should match how often the site changes:

  |  Site type |  Suggested frequency |  
   |  Brochure site, rarely updated |  Weekly |  
 |  Blog with regular posts |  Daily, or after each publishing session |  
 |  WooCommerce or membership site |  Daily at minimum; hourly for high-volume shops |  
 |  Any site |  Before every update, migration or major change |

Automated, scheduled backups are the only reliable approach. A manual backup routine
depends on someone remembering, and people forget — usually in the same week something
breaks. Schedule backups to run automatically and store them off-site, and set up
a notification if a scheduled backup fails.

## Choosing a Backup Method

**Option A: A backup plugin.** Plugins such as UpdraftPlus create full backups (
files plus database) on a schedule and send them to remote storage such as Google
Drive, Dropbox or Amazon S3. This is the right choice for most site owners: no command-
line work, scheduled runs, and a one-click restore from the WordPress admin. Use
a well-maintained plugin from the official WordPress.org directory, keep it updated,
and check that its restore feature is included in the version you use — some plugins
reserve one-click restore for paid versions.

**Option B: Your host’s backup system.** Many hosts take automatic backups of the
whole account. These are a useful safety net, but do not rely on them alone: check
the retention period (how many days back you can restore), whether you can download
the backup yourself, and whether restoring is self-service or requires a support
ticket. [TO BE CONFIRMED: Offshore Hosting’s backup frequency, retention period 
and restore process for WordPress plans.]

**Option C: Manual backup with WP-CLI or the command line.** For those with server
access, this is fast and scriptable:

    ```bash
    # Export the database
    wp db export backup-2026-10-25.sql

    # Archive the files (from the site root)
    tar -czf site-files-2026-10-25.tar.gz --exclude='wp-content/cache' .
    ```

Always exclude cache directories and other transient data from file archives — they
inflate the backup size and are regenerated automatically.

**A note on phpMyAdmin:** WordPress’s own documentation also describes exporting
the database through phpMyAdmin. It works, but for large databases it is slow and
can time out. Use it for small sites, and prefer a plugin or WP-CLI for anything
substantial.

## Where to Store Backups

A backup stored on the same server as the site protects you against accidental deletion
and bad updates — but not against server failure, a hacked account or a billing 
problem. Follow the 3-2-1 rule as a minimum:

 * **3 copies** of your data (the live site plus two backups).
 * **2 different media or locations** (for example, the server and a cloud storage
   account).
 * **1 copy off-site** (a different provider or a local drive you control).

Practical setup for most WordPress owners: the backup plugin sends each scheduled
backup to a cloud storage account, and you keep a recent copy downloaded locally
as well. Encrypt backups that contain customer data, and make sure the storage account
itself is protected with a strong password and two-factor authentication — a backup
containing your database is a copy of your entire site, including hashed user passwords.

Also check retention: keeping every backup forever wastes storage and money. A sensible
rotation is daily backups for the last 7 days, weekly backups for the last month,
and monthly backups for the last few months. Make sure at least one backup predates
any recent change, so you can restore to a point before a problem appeared.

## How to Restore WordPress

Restoring is the part almost nobody practices — and the part that matters. There
are two scenarios.

### Scenario 1: The site still exists, but something is broken

This is the common case: a bad plugin update, a corrupted theme, or content that
was deleted by mistake. If you can still reach the WordPress admin, restore through
your backup plugin: select the backup, choose a full restore (files plus database),
and let the plugin do the work. **Warning:** restoring the database overwrites the
current database. Anything published or ordered since the backup was taken will 
be lost. If the problem is only in the files (a broken theme, for example), restore
the files only and leave the database alone.

### Scenario 2: The site is gone or unreachable

If the WordPress admin is inaccessible, restore manually:

 1. **Create a fresh database** (or empty the existing one) and note the credentials.
 2. **Upload the files.** Extract the file archive into the site’s directory, or upload
    via SFTP.
 3. **Import the database.** From the command line:
     `bash mysql -u username -p database_name
    < backup-2026-10-25.sql Or import the SQL file through phpMyAdmin.
 4. **Check `wp-config.php`.** Confirm the database name, user, password and host match
    the new database. If you moved to a different domain, you will also need to update
    the site URL — the `wp search-replace` command in WP-CLI handles this safely on
    the restored copy.
 5. **Fix file permissions** if the upload changed them, and clear any cache.

After either scenario, verify the restore: load the homepage, a post, and the admin
area; log in; check that recent content is present; and test any forms or checkout
flow. A restore that “completed” but left the site half-working is not a successful
restore.

## Test Your Restore Before You Need It

This is the single most valuable habit in this guide. At least once a quarter — 
and after any change to your backup setup — perform a test restore to a staging 
site (see [how to build a safe WordPress staging workflow](https://offshorehosting.pk/blog/how-to-build-a-safe-wordpress-staging-workflow)).
The test answers the only question that matters: does this backup actually bring
the site back?

A test restore catches the failures that silent backup jobs hide: a plugin that 
stopped including the uploads folder after an update, a backup that is too large
for the restore tool to handle, a database export that silently truncated, or credentials
that changed. Finding any of these during a calm afternoon is a minor fix. Finding
them during an outage is a crisis.

Keep a short log: date of the test restore, which backup was used, whether it succeeded,
and how long it took. That log is also useful evidence if you ever need to demonstrate
due diligence to a client or insurer.

## Backup Before Every Update

Backups and updates are linked. Every core, plugin or theme update should be preceded
by a fresh backup — even if a scheduled backup ran an hour ago. The reason is simple:
the backup you need is the one taken immediately before the change that broke things.
This is part of a safe update routine; see [how to update WordPress plugins and themes safely](https://offshorehosting.pk/blog/how-to-update-wordpress-plugins-and-themes-safely).

## Sources

 * WordPress: Backing up your database: https://developer.wordpress.org/advanced-
   administration/security/backup/database/
 * UpdraftPlus plugin: https://wordpress.org/plugins/updraftplus/
 * WP-CLI: https://wp-cli.org/
 * Restore WordPress backups manually (phpMyAdmin and FTP): https://wp-umbrella.
   com/blog/restore-wordpress-backups-manually/

## Sources

 * {‘title’: ‘WordPress: Backing up your database (Advanced Administration Handbook)’,‘
   url’: ‘https://developer.wordpress.org/advanced-administration/security/backup/
   database/’}
 * {‘title’: ‘UpdraftPlus — WordPress backup plugin’, ‘url’: ‘https://wordpress.
   org/plugins/updraftplus/’}
 * {‘title’: ‘WP-CLI — command-line interface for WordPress’, ‘url’: ‘https://wp-
   cli.org/’}
 * {‘title’: ‘Restore WordPress backups manually (phpMyAdmin and FTP)’, ‘url’: ‘
   https://wp-umbrella.com/blog/restore-wordpress-backups-manually/’}