How to Back Up a WordPress Site: 3 Easy Methods

The Only Rule That Matters

A backup you have never restored is not a backup. It is a file you hope works. Every week, site owners lose years of content because they discovered, at the worst possible moment, that their backup was incomplete, corrupted, stored on the same server that failed, or set to exclude the very thing they needed.

This guide covers three practical methods, from the simplest host-level option to a full manual copy, plus the part almost everyone skips: testing a restore. By the end you will have a working backup system and, more importantly, confidence that it will actually save you when something breaks.

What a Complete WordPress Backup Contains

WordPress lives in two places, and you need both.

The database. Contains posts, pages, comments, users, settings, and plugin configuration. Without it, your files are just an empty shell.
The files. Contains WordPress core, themes, plugins, and the entire uploads folder with your images, videos and documents.

A backup missing either half is incomplete. A database-only backup restores your content but loses images. A files-only backup restores images but loses everything you wrote. Many “my backup did not work” stories come down to exactly this.

What You Should Back Up, and How Often

Content type	Suggested frequency	Notes
Database	Daily for active sites	Changes every time you publish or comment
Uploads folder	Weekly	Changes when you add media
Full site	Weekly or before every update	Best safety net for plugin and theme changes
Retention	Keep several versions	A daily cycle kept for a week catches most problems

Before any major action, take an extra backup regardless of the schedule: before updating WordPress core, before a big plugin update, before changing hosts, before editing theme files, and before running a database search-and-replace.

Method 1: Your Host’s Built-In Backups

Most hosting companies provide automatic backups as part of the plan. This is the easiest starting point, but there are three things to verify rather than assume.

Frequency. Daily is far better than weekly for an active site.
Retention. How many days or versions are kept? If it is only one snapshot, a problem that goes unnoticed for a week may already have overwritten your good copy.
Restore access. Can you restore a single file or the database separately, or only the whole account? Single-item restore saves enormous time and avoids losing recent content during a rollback.

These backups are a good baseline, but never your only copy. If your hosting account is compromised or suspended, everything in it, including the backups, becomes inaccessible. Always keep an off-host copy as well.

Method 2: A Backup Plugin (Recommended for Most Sites)

A backup plugin gives you control over scope, schedule and destination, and lets you move a site between hosts. Free options handle most small sites well.

Setup in six steps

Install the plugin and open its settings.
Choose what to include: database plus files, or database only for a lighter, more frequent schedule.
Set a schedule. A common arrangement is a daily database backup and a weekly full backup.
Choose where copies go. Do not leave them on the same server. Use a cloud storage destination or download them to your computer.
Set retention rules so old copies are deleted automatically and do not fill your storage.
Run the first backup manually and confirm it completes without errors.

What to check in the log

Size. A surprisingly tiny archive for a site with lots of images usually means the uploads folder was excluded.
Completion status. Partial backups show as “finished with warnings”. Treat warnings as failures until you understand them.
Destination. Confirm the file really arrived where you expect, by logging into that storage account and looking.

Method 3: Manual Backup via cPanel

The manual method is slower but gives you a complete, portable copy you can store anywhere. It is worth knowing because it works even when plugins are broken.

Backing up the files

Open cPanel and launch File Manager.
Go to public_html, select all files, and compress them into a single archive.
Download that archive to your computer or move it to external storage.

For large sites, use an FTP client to download the wp-content folder instead, as it avoids browser download limits.

Backing up the database

In cPanel, open phpMyAdmin.
Select your WordPress database on the left.
Click Export and choose the standard SQL format.
Download the exported file and store it with the files archive, noting the date in the filename.

Cleaning the export and importing it back on a restore is straightforward, which makes this method dependable for migrations as well as recovery.

Where to Store Backups

Follow the rule of three places: the server, a cloud storage account, and one offline or off-site copy. Practical destinations include your backup plugin’s cloud integration, a Google Drive or Dropbox folder, an external drive, or a cheap object storage account.

Two warnings. First, never store your only copy on the same hosting account, because account-level failure, suspension or malware takes the backup with it. Second, treat backups as sensitive data: a database dump contains user emails and hashed passwords, so use a storage account with two-factor authentication enabled and avoid sharing download links.

How to Restore: The Part You Must Practise

Restoring from a plugin is usually a single click: pick the backup, confirm the warning about overwriting current data, and wait. The important part is what you do around it.

Before restoring, download the current state if there is any chance you need something published after the backup was taken.
Put the site in maintenance mode if the restore will take more than a few minutes.
Restore the database and files together. Mixing an old database with new files causes version mismatch errors.
After restoring, clear all caches: plugin cache, server cache and CDN cache. A restored site still serving cached pages confuses everyone.
Log in, check the homepage, check a few posts, check images, and resubmit nothing to search engines until you are sure the site is stable.

Once a quarter, restore a backup to a staging site or a subdomain and confirm it works. This is the difference between owning a backup and hoping you do.

A Restore Test in Ten Minutes

Pick yesterday’s backup archive.
Create a subdomain such as test.yourdomain.com.
Restore the backup into that subdomain, or use your plugin’s clone or migration feature.
Open the test site, log in, and check that posts, images, menus and plugins look right.
Note anything missing, then delete the test site and fix your backup settings.

If the test fails, you have just avoided a disaster. If it succeeds, you now know your system works, which is worth more than any checklist.

Common Backup Mistakes

Storing backups inside the WordPress uploads folder. Publicly guessable and included in the next backup, doubling its size.
Never checking the logs. A plugin can fail silently for weeks.
Backing up before an update but after the change that broke things. Always back up before, and label the archive with the date and reason.
Relying on one method. Plugin plus host plus occasional manual export is far more resilient than any single approach.
Forgetting email. If your site sends email through a contact form configured with SMTP details stored in a plugin, make sure those settings are backed up with the database.
Not backing up before a migration. Migrations change URLs and databases; without a backup you cannot go back.
Assuming your host’s backup covers your plugin subscriptions, licences and DNS settings. Keep a separate note of licenses and DNS records.

Backups Before the Risky Jobs

Some tasks deserve their own backup regardless of your schedule, because they are the ones most likely to end badly.

Core and plugin updates. Most go smoothly, but a single incompatible update can take a site down for hours.
Theme changes. Switching themes can hide or break widgets, menus and custom fields that the new theme does not display.
Migrations. Moving hosts or domains rewrites URLs in the database, and mistakes there are difficult to untangle without a rollback point.
Search-and-replace operations. A single badly formed replace can corrupt serialised data across the whole site.
New plugins. Especially large ones that create their own database tables.

Label these backups with what you were about to do. Six months later, “before Rank Math install” tells you far more than “backup final”.

What a Backup Does Not Protect

It is worth being clear about the edges, because people are sometimes surprised during a crisis.

Your domain name. A backup cannot restore an expired domain or undo a hijacked registrar account. Enable auto-renew and two-factor authentication at your registrar.
DNS records. These live at your registrar or DNS provider, not in WordPress. Keep an export or a screenshot of your records.
Email. If you use email hosting separate from the site, it needs its own backup.
Third-party services. Data inside an analytics, newsletter or payment service is not part of your site backup, though most of those tools allow you to export contacts and reports.
Plugin licences. A restored site with expired licences will not receive premium updates, which can be a security problem. Keep a list of the licences and their renewal dates.
Anything you never uploaded. Files sitting on your computer that were meant to be added to the site are not covered.

Keep a short “site inventory” document listing your registrar, host, DNS provider, key plugins with licences, and backup destinations. During an emergency, that single page saves hours of detective work.

Frequently Asked Questions

Do I need to back up if my host does it automatically?

Yes, but as a second layer rather than a replacement. Host backups are convenient for quick rollbacks. Your own off-site copy protects you from account-level failures and gives you portability if you change hosts.

How long does a restore take?

A small site usually restores in a few minutes. Large sites with many images can take half an hour or more, depending on server speed and archive size.

Can I keep a backup in Google Drive for free?

Free tiers have storage limits, so a growing site will need tidying or a paid plan. The key requirement is that the destination is off your hosting account.

Should I back up before or after updates?

Before, always. The point of the backup is to return to the working state you had prior to the change.

What if my site is in maintenance mode and I need to restore?

Restoring works regardless of the front end. If the admin area itself is broken, restore the files and database through cPanel or ask your host to restore from their snapshot.

Backup Questions Before You Trust Your Setup

Should I back up a staging site as well?

Yes, briefly. Staging environments are where you test risky changes, so a rollback point is useful. Keep the schedule lighter, and do not keep long-term archives: staging backups accumulate storage and often contain database copies with user data you do not want lying around.

How large should a backup file be?

There is no fixed answer, but the size should roughly match the content on your site. As a guide, compare the archive size with the total size of your uploads folder. If the backup is a fraction of that, images are probably missing. If it is dramatically larger, you may be backing up other backups.

Do incremental backups replace full backups?

No; they work together. Incremental backups store only the changes since the last run, which saves time and space, but they depend on the chain being intact. Keep regular full backups as the foundation and use incremental runs in between.

What is the correct retention policy?

Enough versions to cover the period in which you would notice a problem. For an active site, daily backups kept for seven to fourteen days plus monthly copies kept for a few months covers most situations. The oldest copy is only useful if you would actually restore from it.

Can I restore a backup on a different host?

Yes, and this is a genuine advantage of plugin-based backups: they double as migration tools. Restore the archive on the new host, update the settings, and check the site. Practise this once on a test domain so you are not learning it under pressure.

Final Thoughts

Backups are boring until the day they are the most important thing you own. Set up two methods, store copies away from your server, schedule them to run automatically, and once a quarter actually restore one to a test location. That routine takes an afternoon to establish and protects everything you have built from accidents, updates gone wrong, and the occasional attack.