To back up WordPress properly, capture both your files and your database on a schedule, send at least one copy off your hosting account, and keep an extra copy before every update. Then do the step almost everyone skips: restore one to a staging site and confirm it works, because an untested backup is a guess.
Here is a question that sorts real backup setups from imaginary ones. If your site broke right now, could you restore it to how it looked yesterday morning, inside an hour, without calling your host? If the honest answer is “probably,” you do not have a backup system. You have a backup plugin and a hope. This guide covers both halves of the job, and gives the restore half the attention it actually deserves.
What a complete WordPress backup actually contains
A WordPress site is two separate things, and a backup needs both or it will not restore.
Your files. The wp-content folder holding your themes, plugins and the uploads directory with all your media, plus the WordPress core files and wp-config.php.
Your database. A separate MySQL database storing every post, page, user, comment, product and setting. Your content is not in your files; it is here.
Restoring one without the other produces a site that looks broken in confusing ways. A files-only restore gives you a working design with the wrong content. A database-only restore gives you correct content with missing images and a theme that does not load. Both halves must come from the same point in time, or you get a site that half-matches itself.
This is also why “I downloaded my theme” is not a backup, and why exporting your posts from Tools then Export is only a partial one. That export contains your content but not your media files, settings, plugins or users.
Why your host’s backups are not enough on their own
Most hosts include automatic backups, and they are genuinely useful. They are not a complete strategy, for four specific reasons.
They live in the same account as your site. If your hosting account gets suspended, corrupted or compromised, the backups sitting inside it can go with it. That is the single most common way people discover their backups were theoretical.
Retention is often short. Many hosts keep seven to thirty days. Site compromises are frequently discovered weeks after they happened, so by the time you know you need a clean backup, the clean one may already have rolled off. Aim for thirty days minimum, more if you can.
You usually cannot restore elsewhere. If you need to move to a different host, or spin the site up somewhere to test, a host-locked backup does not travel.
You do not control the schedule. A nightly backup means anything you published or sold today is not protected yet.
The right mental model: host backups are your emergency parachute; a backup you control, stored in your own cloud account, is your primary recovery system. Run both and you have two independent ways back.
The 3-2-1 rule
The backup industry has used the same rule for about twenty years because it survives nearly any single disaster:
- 3 copies of your site: the live site plus two backups
- 2 different storage types, so one failure cannot destroy both
- 1 copy off your server, somewhere your hosting account cannot reach
That last point carries most of the value. It is what protects you when the problem is the host itself, and it is the reason a ransomware demand or a compromised site becomes an inconvenience rather than a catastrophe. A current, off-server backup is the one control that lets you rebuild on your own terms instead of negotiating.
Practically, for a small business site this looks like: live site, plus your host’s automatic backups, plus a plugin sending copies to your own Google Drive, Dropbox or S3 account.
How often should you back up?
Match the schedule to how fast your site changes, since the real question is how much work you are willing to lose.
| Site type | Database | Files |
| Brochure site, rarely updated | Weekly | Weekly |
| Active blog or business site | Daily | Weekly |
| Busy site with enquiries or bookings | Every 6 to 12 hours | Daily |
| Online store taking orders | Hourly | Daily |
Files change less often than the database, so backing them up less frequently is fine and saves storage. Your database holds every new order, comment and content edit, which is why it needs the tighter schedule.
One rule sits above all of it: always take a fresh backup immediately before you change anything. Before a WordPress, plugin or theme update, before editing functions.php, before installing a plugin you have not used before, and before any migration. This is the single habit that turns a broken update from a six-hour reconstruction into a five-minute rollback. It matters more than usual right now: of the 11,334 WordPress vulnerabilities recorded in 2025, roughly 91% were in plugins, so plugin updates are both necessary and the most likely thing to break something.
Method 1: A backup plugin (best for most sites)
A plugin is the right primary method for most site owners because it runs on a schedule, sends copies to storage you own, and restores from inside the dashboard.
UpdraftPlus is the most widely used, with over three million active installations as of mid-2026. The free version handles scheduled backups of files and database, with storage to Google Drive, Dropbox, Amazon S3 and others. Setup takes under ten minutes.
The setup that actually protects you:
- Install and activate the plugin from Plugins, then Add New.
- Open its settings and connect a remote storage destination in your own account. This step is the whole point; a plugin backing up to your own server has solved nothing.
- Set separate schedules for files and database using the table above.
- Set retention to at least thirty days, or as many copies as your storage allows.
- Run one backup manually and confirm the files actually appear in your cloud storage.
Other established options include BlogVault (strong incremental backups and a reliable restore workflow, particularly for WooCommerce), WPvivid, and Solid Backups. If your site is over roughly 2GB, look specifically for incremental backups, because full backups on shared hosting run slowly and can time out silently, leaving you with a backup that reports success and contains nothing usable.
The criterion that separates a backup plugin from a restorable backup plugin: can it restore to a different host in one click? Many cannot. Check before you need to know.
Method 2: Your host’s backups (keep them as the second layer)
Turn these on if they are not already, and find out three things: how often they run, how long they are kept, and how you actually trigger a restore. Most hosting panels have a Backups or Restore section, and many hosts will restore for you on request.
Their strength is that they work when WordPress itself is unreachable, which is exactly the situation where a dashboard plugin cannot help you. If you are staring at a white screen or a 500 error and cannot log in, a host-level restore is often the fastest way back.
Method 3: Manual backup (for one-off moments)
Useful before a risky change, or when you want a copy in your own hands right now.
Files: connect over FTP or your host’s file manager and download the whole public_html directory, or at minimum wp-content plus wp-config.php.
Database: open phpMyAdmin from your hosting panel, select your database, click Export, choose Quick and SQL format, and download the .sql file.
Keep both files together in one dated folder, because a files backup without its matching database is not a restore point. If you are comfortable at the command line, WP-CLI does both faster.
How to restore a WordPress backup
This is the part most guides rush. Work through it in order, and read the whole section before starting rather than midway through a live incident.
Before you restore anything: take a backup of the current broken state. This sounds pointless and is not. If the restore goes wrong, or if the current version contains something you still need (recent orders, a new page), you cannot get it back once it is overwritten. This applies even to a hacked site, where the compromised files are also evidence of how the attacker got in.
Restoring with a plugin (easiest). If you can reach wp-admin, open your backup plugin, find the backup set with the date you want, and click Restore. Select all components (database, plugins, themes, uploads, others) unless you specifically know you only need one. The plugin unpacks everything and swaps it in. This usually takes a few minutes.
Restoring from your host. If wp-admin is unreachable, log into your hosting panel, open the Backups or Restore section, pick the restore point, and confirm. Some hosts run this themselves through a support ticket, which is often faster than fighting the panel.
Restoring manually. Upload your files back over FTP to the site’s root. Then in phpMyAdmin, select your database, drop the existing tables, and import your .sql file. One step people miss: the credentials in wp-config.php must match the database you just imported into. If they do not, you will see the error establishing a database connection, which is a configuration mismatch rather than a failed restore.
If only part of the site is wrong, restore only that part. A bad plugin update needs the plugins folder, not the whole site. A deleted page needs the database. Restoring everything when you only needed one component throws away work you did not have to lose.
Why restores fail (the four causes)
Restores fail for a small and predictable set of reasons. Knowing them in advance is most of the protection.
1. Missing files. The archive is incomplete, most often missing the uploads folder or custom theme files. The site comes back with broken images and a theme that will not load. This is what silent timeouts on large full backups produce.
2. An incomplete database export. The SQL file is truncated, damaged, or too large for the import method being used. Large databases frequently exceed phpMyAdmin’s upload limit, which is where command line tools or a plugin become necessary.
3. Version mismatch. The restored site expects a different PHP version, or a different WordPress and plugin combination, than the server now runs. Reported analysis puts incomplete files and version mismatches together at the majority of restore failures. This is also why restoring a very old backup onto a modern server can break in ways the backup itself did not cause.
4. No verification. The restore looks fine, and nobody discovers otherwise until a customer tries the contact form, the checkout or the booking flow a week later.
The restore drill: how to test a backup
A backup you have never restored is a guess. Testing one takes under an hour and is the difference between believing you are covered and knowing it.
The method: create a staging site (most decent hosts offer one-click staging), restore your most recent backup onto it, and check that it actually works. Not just that the homepage loads, but that the things your business depends on function. Do this once now, and then roughly monthly, or at minimum after any change to your hosting, your backup plugin or your site’s size.
Post-restore verification checklist:
- Homepage and three or four key pages load correctly
- Images appear (a broken media library is the classic incomplete-restore symptom)
- You can log in to wp-admin
- Contact forms send and arrive
- Checkout or booking completes end to end, if you have one
- Recent content is present, so you know which restore point you actually got
- No errors appearing where content should be
- Site speed is roughly normal rather than suddenly much slower
If the drill fails, you have learned it on a Tuesday afternoon instead of during an outage. That is the entire point.
What backups do not protect you from
Worth being clear about, because backups get treated as a universal safety net and they are not.
A backup of an already-infected site. If malware sat undetected for six weeks, your recent backups contain it. Restoring reinstalls the infection. This is why retention length matters and why a compromise needs proper cleanup and the entry point closed, not just a restore.
Anything outside WordPress. Backups do not cover your domain registration, DNS records, email, or third-party services connected to the site.
Slow degradation. If your site has been getting worse gradually, restoring last night’s copy restores the problem.
Bad decisions with a lag. A restore point from before a change only helps if you notice within your retention window.
Backups are recovery, not prevention. They pair with updates, security and ongoing maintenance rather than replacing them.
Common mistakes
- Backups stored only on the same server. The most common and most consequential mistake.
- Never testing a restore. Second most common. In a 2025 survey across eight countries, around 9% of people said they never back up anything at all, and only about two thirds back up regularly, so plenty of sites are running with nothing.
- Files without the database, or the other way round. Neither restores alone.
- Retention too short. Thirty days minimum, because problems surface late.
- No pre-update backup. The cheapest insurance available, skipped constantly.
- Assuming a green “success” message means it worked. Silent timeouts produce successful-looking empty backups. Check the file size in your storage.
Key takeaways
A complete WordPress backup captures your files and your database from the same moment, because neither restores without the other.Your host’s backups are a useful parachute but not a strategy, since they live in the same account, have short retention and rarely move to another host, so run a plugin sending copies to storage you own as well.
Follow the 3-2-1 rule, match your schedule to how fast your site changes, and always take a fresh backup immediately before any update.
Then test a restore on a staging site and verify the things that matter, because incomplete files, truncated databases, version mismatches and missing verification cause nearly every failed restore. An untested backup is a guess, and the day you find out is the worst possible day to find out.
Frequently Asked Questions
How do I back up a WordPress site?
Install a backup plugin such as UpdraftPlus, connect it to cloud storage you own like Google Drive or Dropbox, and schedule backups of both your files and your database. Keep your host’s automatic backups running as a second layer, and take an extra manual backup before every update.
What is included in a full WordPress backup?
Two halves: your files (the wp-content folder with themes, plugins and uploads, plus core files and wp-config.php) and your MySQL database containing posts, pages, users, orders and settings. Both must come from the same point in time, because restoring one without the other leaves an incomplete site.
How do I restore a WordPress backup?
If you can reach wp-admin, open your backup plugin, choose the backup set by date, and click Restore with all components selected. If the dashboard is unreachable, restore from your hosting panel instead. Always back up the current broken state first, in case the restore goes wrong.
Are my host’s backups enough?
Usually not on their own. They sit in the same account as your site, so an account compromise or suspension can take both. Retention is often short, and they rarely restore to a different host. Treat them as a second layer alongside backups stored in your own cloud account.
How often should I back up my WordPress site?
Match it to how fast your site changes. Brochure sites can run weekly, active business sites daily for the database and weekly for files, and stores taking orders hourly for the database. Always take an extra backup immediately before any update or risky change.
How do I know my backup actually works?
Restore it. Create a staging site, restore your most recent backup onto it, then check that pages load, images appear, you can log in, and forms or checkout complete. Repeat monthly. A green success message in your dashboard does not confirm the archive contains a usable site.
