The short answer
A good WordPress backup setup saves both the database and the files, runs on a schedule that matches how often your site changes, and stores copies away from the server the site lives on.
It also takes an extra backup before every update. And at least a few times a year, someone restores a copy onto a test site, such as a staging site, to prove it works.
Plenty of sites have the first part, because a backup plugin was installed at launch. Far fewer have ever had a restore tested. That gap is the whole point of this guide. Backups are the safety net, not the lock on the door; for prevention, work through our WordPress security checklist as well.
What a complete WordPress backup includes
A WordPress site is two things stitched together, plus one small file that joins them. Miss any of the three and the restore will be incomplete.
The database
This holds your pages, posts, settings, users, form entries and, on a WooCommerce store, every order and customer record. Restore files without the database and you get an empty shell.
The wp-content folder
Uploads (every image and PDF you have added), your theme and your plugins. Restore the database without uploads and every page loads with broken images. Some backup setups leave the uploads folder out to keep file sizes down, so check yours.
wp-config.php
This file tells WordPress how to reach the database and holds security keys. You can rebuild it, but having it saves time. Treat it as sensitive, because it contains the database password.
What a backup does not cover
Your domain registration, DNS records and email accounts usually sit outside WordPress entirely. Keep a note of DNS settings and registrar logins separately, especially before you transfer a domain to another registrar. The same goes for the certificate: after a restore to a new server, SSL and HTTPS may need setting up again.
What are the three ways to back up WordPress?
There are three common approaches, and a careful setup often uses two of them. What your host offers depends on whether you are on shared, cloud or managed hosting, so check your plan before relying on it.
Host snapshots copy the whole account at the server level. They are easy to restore from the control panel but usually live on the host's own infrastructure. Backup plugins run inside WordPress, can send copies to cloud storage, and restore through the dashboard, as long as the dashboard still works. Manual exports use phpMyAdmin or the WP-CLI command wp db export for the database, plus a file download of wp-content. They give full control but depend on someone remembering.
| Method | Effort to set up | Stored off-site? | Restore speed | Main weakness |
|---|---|---|---|---|
| Host snapshot | None, if included | Often not | Fast, from control panel | Tied to the host account |
| Backup plugin | Low | Yes, if cloud storage is connected | Moderate | Fails if WordPress or storage login breaks |
| Manual export (phpMyAdmin or WP-CLI) | Moderate | Wherever you put it | Slow, technical | Depends on someone doing it |
Where to keep the copies
A backup stored only on the same server as the site is not really a backup. If the server fails, the account is suspended, or an attacker gains access, the copies go with it.
The widely used 3-2-1 rule is a good target: three copies of your data, on two different kinds of storage, with one kept off-site. For a small business site that can be as simple as the live site, a host snapshot, and a plugin sending copies to a cloud storage account the business owns.
Two practical points matter more than the rule itself:
- Who holds the keys. The cloud storage account should belong to the business, not to a freelancer's personal account. When the relationship ends, the backups should stay with you.
- Where the storage sits. Pick a storage region deliberately and write it down, since backups contain customer data. For the separate question of whether the live server's country matters for search, see does server location affect SEO.
How often, and how long to keep them
Match the schedule to how much you could afford to lose. Ask: if the site failed right now, how many hours of changes could we re-enter by hand?
Brochure or company site
Content changes a few times a month. A daily or weekly automatic backup is usually enough, with around a month of copies kept so you can go back past a problem noticed late.
WooCommerce store
Orders and customer accounts change every hour. Back up the database at least daily, more often during sales peaks such as 11.11 or year-end, and keep a longer history. Restoring yesterday's database also removes today's orders, so note the time of the last good backup before you restore anything.
Before every update
Take a fresh backup immediately before updating WordPress, the theme or plugins. It is the copy you are most likely to need.
How do you test a restore before you need one?
The restore drill is where most setups fail quietly. Common problems only show up when you try: large media libraries that time out halfway, folders excluded without anyone noticing, and cloud storage connections whose access tokens expired months ago. Run the drill every quarter on a staging copy, never on the live site. If you ever face a real incident, our guide on how to fix a hacked WordPress site explains how clean backups fit into recovery.
- Step 1
Pick a recent backup
Choose the latest full copy, and note its date and size. A file far smaller than usual is a warning sign.
- Step 2
Create a staging copy
Use your host's staging tool or a spare subdomain protected with a password so search engines cannot index it.
- Step 3
Restore database and files
Import the database, upload wp-content and adjust wp-config.php for the staging database.
- Step 4
Click through key pages
Home, a service page, a blog post and, for stores, a product page and the cart. Look for missing images.
- Step 5
Log in and check the admin
Confirm users, recent posts and, on a store, recent orders are present.
- Step 6
Record the result
Write the date, the backup used and anything that failed in your maintenance log, then delete the staging copy.
Backups and personal data under PDPA
A backup is a full copy of your database, so it contains everything the live site holds: enquiry form entries, customer names and phone numbers, order histories and, for clinics, sometimes health details. Thailand's Personal Data Protection Act expects a data controller to keep appropriate security measures for personal data, and that duty does not stop at the live site. A leaked backup is still a data breach and can lead to the sanctions described in our guide to PDPA penalties and fines.
- Access: limit who can download backups, and use two-factor login on the storage account.
- Location: know which provider and region the copies sit in, and mention storage by service providers in your privacy notice where relevant.
- Retention: do not keep backups forever. Old copies hold data you may have been asked to delete.
- Encryption: choose storage or a plugin option that encrypts copies at rest where available.
This is general guidance, not legal advice; for your specific obligations, check the PDPC's published material or ask a lawyer.
Handing backups to a maintenance partner
If you pass backups to a developer or agency, ask these questions before you agree anything:
- Where exactly are the copies stored, and in whose account?
- How often do they run, and how long are they kept?
- When was the last restore test, and can I see the log?
- If we part ways, how do I get the latest copies?
Clear answers to all four are a good sign. Backups, restore tests and update checks are part of the ongoing WordPress maintenance we offer after launch, and our maintenance pricing page explains what shapes the cost for your site.
More WordPress care guides
Sources
- WordPress Advanced Administration Handbook: Backups
- WP-CLI: wp db export
- Personal Data Protection Committee (PDPC) Thailand
Builds and ranks the websites: the systems behind the 17 client sites whose Search Console numbers we publish. This guide was written by the Website Development Bangkok team. More about us