How to Back Up Your WordPress Site

A backup you have never restored is a hope, not a backup. This covers what to capture, how to automate it, and how to test that it works — before you need it.

What a complete backup contains

WordPress stores itself in two places, and a backup missing either one is not a backup.

• Files — everything under public_html: WordPress core, your themes, your plugins, and wp-content/uploads, which holds every image and document you have ever added.
• Database — every post, page, comment, user account, and plugin setting. Without it, restored files produce an empty site.

Copying only wp-content is the most common mistake. It saves your uploads and misses all of your content.

Option 1 — JetBackup (automatic, included)

Eligible plans include JetBackup, which takes daily off-site snapshots without you configuring anything.

In cPanel, open Files > JetBackup. From there you can:

• Browse daily restore points by date
• Restore the full account, or just the files, or just a database
• Restore a single file or folder — invaluable when one plugin update breaks one thing and you do not want to roll the entire site back
• Download a snapshot to keep locally

Restoring is a two-click operation and you get an email when it finishes.

Option 2 — cPanel manual backup

Useful before a risky change, when you want a copy in your own hands.

Files

Files > File Manager, select public_html, click Compress, choose zip, then download the archive.

Database

Databases > phpMyAdmin, select your WordPress database in the left sidebar, open the Export tab, keep the Quick method and SQL format, and click Export.

Store both files together with the date in the filename. They are only useful as a pair.

Option 3 — A backup plugin

Plugins such as UpdraftPlus or Duplicator run inside WordPress and can push backups to Google Drive, Dropbox, or S3. They are convenient and they schedule easily.

Two caveats worth knowing. A plugin backup runs as PHP, so a very large site can hit execution limits mid-run and produce a truncated archive that looks fine until you try to restore it. And a plugin cannot help if the failure is WordPress itself failing to load. Treat plugin backups as your convenient layer and JetBackup as your safety net, not the other way round.

How often, and how many

• Daily for anything with orders, comments, or regular publishing.
• Weekly for a brochure site that rarely changes.
• Always immediately before a core, theme, or plugin update, or any change to wp-config.php or .htaccess.

Keep at least a month of history. Some problems — a slow database corruption, an intrusion that sat quiet for weeks — are only visible well after they start, and by then a three-day retention window has already overwritten the last clean copy.

Test the restore

This is the step almost everyone skips.

At least once, restore a backup into a subdomain or a staging area and click through the result. Confirm images load, the admin area opens, and recent posts are present. You want to discover that your database export was incomplete on a quiet Tuesday, not during an outage.

Restoring in a hurry

1. Do not delete anything yet. A broken site is still evidence, and sometimes the fix is smaller than a full restore. 2. If a single update caused it, restore just that plugin's folder rather than the whole account. 3. If the site will not load at all, restore the most recent full snapshot from JetBackup. 4. After restoring, clear every cache — the plugin's, LiteSpeed's, and Cloudflare's — or you will keep seeing the broken version.

If you are not sure which restore point is the right one, message support before restoring. We can look at the snapshots with you, and an unnecessary full restore can lose content added since the backup was taken.