How to Back Up Your WordPress Site: Files, Database, and a Restore You Have Tested
Last updated: November 5, 2026 · Steps checked against WordPress.org's official backup documentation (sources at the bottom)
We may earn a commission if you buy through links here — it never changes our picks.
A backup is a complete copy of your website, stored somewhere other than the website itself, that you can put back when something breaks. Something eventually does: an update that conflicts with a plugin, a hosting failure, a hacked page, or a person deleting the wrong thing. WordPress.org's own documentation puts it without drama: problems inevitably occur, and a backup is what lets you act instead of starting over.
The single fact that shapes this whole guide is that a WordPress site is not one thing. It is two: a set of files and a database, stored in different places and copied by different means. Most failed backups failed right here, by copying one half and assuming the other came along. This guide shows you what a complete backup includes, gives you two routes to make one (a plugin route, and a manual route that teaches you what the plugin is doing), then covers where the copies should live and how to prove a backup can actually be restored. Budget about half an hour for your first one.
What you need
- Your WordPress admin login. The plugin route happens entirely inside the dashboard.
- Your hosting account login. The manual route uses tools in the hosting control panel, and you will want it for checking what backup tools your host provides.
- Somewhere for the copies to live that is not the site itself: a cloud storage account, space on your own computer, an external drive, or some combination. The storage section below explains the pattern to aim for.
- A note about your host's backups. Many hosts take their own backups, and WordPress.org is clear-eyed about them: most hosts back up the whole server, but requesting your site's copy takes time you may not have mid-crisis. Check what your host offers, by all means, and still make your own. Yours is the copy you control.
What a complete backup actually includes
The files are everything in your site's folder on the server: the WordPress software itself, your themes, your plugins, and your uploads, which is your media library of images and documents. Two individual files deserve naming. wp-config.php is the file that holds the keys connecting your site to its database; without it, a restored site cannot find its content. .htaccess holds server settings for the site's addresses. If it lives in the folder, it goes in the backup.
The database is a separate store, usually a system called MySQL or MariaDB, and it holds the content itself: every post, page, and comment, plus your users, your settings, and, if you run one, your store's orders and products. WordPress.org's summary is blunt: if the database is erased or corrupted, you stand to lose everything you have written.
Here is the trap, stated the way the official documentation states it: backing up the files does not back up the database. The database lives outside the site's folder, so copying the folder misses it entirely. When you back up the database, you create an export file, usually ending in .sql or a compressed version of it, and that export file is what you store alongside your file backup. The pair, made at about the same time, is one backup set. WordPress.org recommends making the database part first and the files second, so the two halves describe the same moment as closely as possible.
- The site files: WordPress itself, themes, plugins, and the uploads folder.
- wp-config.php and .htaccess, included with the files.
- A database export file (.sql or compressed), made at the same time.
- All of it copied to at least one place that is not the web server.
Route 1: Back up with a plugin
For most small sites this is the right route: a plugin assembles both halves, sends the set somewhere safe, and repeats the job on a schedule. WordPress.org maintains a list of backup plugins in its official plugin directory, which is where to choose from. We do not rank backup plugins here, because the honest differences between the well-kept ones matter less than the settings below, and a neglected setting can gut any of them.
Install a backup plugin from inside WordPress
In your dashboard, go to Plugins → Add New and search for backup. Choose a plugin from the WordPress.org directory that is actively maintained, meaning it has been updated recently and is listed as compatible with your version of WordPress. Install it and activate it. Avoid backup tools offered as downloads from random sites; a plugin that can copy your entire site deserves the official directory's vetting.
Run a full backup, and check what "full" includes
Open the plugin's screen and run your first backup. Before you trust it, find the setting or report that says what went in. You are confirming both halves: database and files, including the uploads folder. Some tools default to database only, or quietly skip large media folders. A backup that turns out to be half a backup is worse than none, because you stopped worrying the day you made it.
Send a copy off the server
If the plugin offers destinations, connect a cloud storage account so each backup lands somewhere other than your web server automatically. Then also download this first backup to your own computer from the plugin's list of completed backups. Two destinations, set up once, and the storage rules in the next-but-one section are already half satisfied.
Turn on the schedule
Set automatic backups to repeat, as often as the site changes. WordPress.org's general suggestion: for smaller sites with fewer posts, weekly is reasonable; for busy sites with a lot of new content, back up daily. Then keep a manual habit alongside the automatic one: run a backup by hand before any update, redesign, or host move. WordPress.org recommends exactly that pairing, an automatic schedule backed by an occasional manual backup, and a fresh backup always before an upgrade.
Backup completed and its contents confirmed as files plus database · one copy downloaded to your computer · one destination off the server connected · schedule switched on.
Route 2: Back up by hand
The manual route is slower, and worth doing once even if you settle on a plugin, because it teaches you where the two halves live. It is also the route that works when a plugin cannot run, on a site that is already broken. The exact screens vary by host, so treat the names below as the pattern to look for rather than a promise about your panel's layout.
Export the database with phpMyAdmin
phpMyAdmin is the standard tool for a site's database, and most hosts include it. Find it in your hosting control panel and open it. Select the database that holds your WordPress data; if several are listed and you are unsure, the database name is written in your site's wp-config.php file. Click the Export tab. The Quick method, with the format set to SQL, is enough for most sites. Click Go, and the export file downloads to your computer.
Copy the files with your host's file manager or an FTP app
FTP (File Transfer Protocol) is the traditional way to copy files between your computer and a server with a small desktop app. Your host's built-in file manager does the same job in the browser. Either way, copy the site's whole folder to your computer. Inside it, be certain you have: the wp-content folder, which holds your themes, plugins, and uploads; wp-config.php; and .htaccess. That last one is a hidden file, so if you cannot see it, turn on the tool's "show hidden files" option rather than assuming it is absent.
Marry the two halves into one dated set
Put the database export in the same folder as the file copy, name the folder with the date, and compress it if you like. One folder, one date, both halves: that is a backup set you can reason about months later, when "backup-final-v2" folders have lost all meaning.
A database export file downloaded · the full site folder copied, wp-content, wp-config.php, and .htaccess confirmed present · both halves together in one dated folder on your computer.
Where your copies should live
A backup stored only on the same server shares the site's fate. If the server fails or the account is compromised, the backup goes with it. The long-standing pattern for avoiding that is called the 3-2-1 rule: keep 3 copies of what matters, on 2 different kinds of storage, with 1 copy kept somewhere else entirely. Our small business security checklist uses the same rule for business files generally; here it is applied to your website.
WordPress.org's version of the same advice is concrete: keep three to five recent backups, with copies in different locations, for example one on the hosting server, one in cloud storage, and one downloaded to your own computer. Recent matters as much as plural. A single perfect backup from eight months ago restores a site you no longer have, missing everything since. A rolling set of recent ones means the worst case is losing a few days, not a year.
- Copy one: with the host or the plugin's on-server store. Convenient, fast to restore, and never your only copy.
- Copy two: cloud storage, sent automatically by the plugin or uploaded by hand after a manual backup.
- Copy three: your own computer or an external drive. The copy that survives even a lost hosting account.
Prove the backup restores
An untested backup is a hope, not a backup. Plugins report success for jobs that produced incomplete files, exports get cut short, and the only way to know a set works is to rebuild a site from it somewhere safe. Once, for your first backup, is enough to learn the shape of the job and to catch a broken setup while nothing is on fire.
Restore to a test copy, never over your live site
Use a staging area if your host offers one, a private subdirectory, or a test installation on your own computer. The live site keeps running untouched while you prove the backup. If your plugin offers its own restore feature, this test copy is where to try it first.
Restore in the official order: files first, then database
WordPress.org gives the restore order as the reverse of the backup order: files back first, into the test site's folder. Then import the database: in phpMyAdmin, select the test site's database, click the Import tab, choose your export file, make sure the format is SQL, and click Go. If the database name or login changed between the original site and the test copy, update the values in wp-config.php to match, which is the other job that file does.
Inspect the rebuilt site like a visitor and an owner
Open the test copy's homepage. Click into a post or page. Confirm your images load, because missing media is the signature of an incomplete file copy. Then log in to the admin area and confirm you can reach the dashboard, see your posts and pages listed, and open a plugin settings screen. A site that displays but will not let you log in is only half restored.
If the test fails, the backup job is not finished
Fix the setup now, while the live site is healthy and you can remake the backup at leisure: check which half was incomplete, adjust the plugin's settings or your manual routine, run a fresh backup, and test again. This loop, done calmly once, is the entire difference between sites that recover in an afternoon and sites that do not recover.
One habit to attach to this: a backup belongs before every risky moment, not just on a schedule. Before updating WordPress, a theme, or plugins, and before moving hosts, run one and download it. If you are planning a move, our guide to moving WordPress to managed hosting starts from exactly that step, because a host move with a proven backup behind it is a chore, and without one is a gamble.
Common beginner mistakes
- Backing up only the files. The most common failure of all. The folder copy looks like the whole site and contains none of your posts, pages, or comments. Files and database, every time, as one set.
- Backing up only the database. The mirror image: your words are safe and your theme, plugins, and every image you uploaded are gone. An export file alone is half a website.
- Keeping every copy on the server. Backups that live and die with the thing they protect. At least one copy belongs somewhere else entirely, per the storage section above.
- Trusting the green checkmark. A plugin's success message means a job ran. The restore test is what means the backup works. Do it once per setup, and again after changing backup tools.
- One old backup. A single set from months ago restores an outdated site and discards everything newer. Keep three to five recent sets and let the oldest fall away as new ones land.
- Backing up on a schedule but not before changes. Updates and moves are when sites break, and they do not check your backup calendar first.
- My backup set contains both halves: the site files and a database export, made at the same time.
- wp-config.php, .htaccess, and the uploads folder are confirmed inside the file copy.
- Copies exist in at least two places besides, or instead of only, the web server.
- I keep three to five recent sets, not one old one.
- Automatic backups are scheduled, and I run a manual one before updates or a host move.
- I have restored a test copy from a backup at least once, and checked pages, images, and the admin login.
Where these steps come from
The procedures in this guide were checked against WordPress.org's official documentation below in November 2026. Individual hosts arrange their control panels differently, so if a tool's location differs on your host, its name will be the same or close. That is the part the documentation guarantees.