Your backup plugin has emailed “Backup completed” every Sunday for a year. Today you need it. You open the zip and find the theme, the plugins, the uploads, and no database. Every post you ever wrote lived in the part that was not there.
That is the first lesson in how to back up a WordPress site: a backup is two things, not one. Most backup failures are someone saving one half and believing they had both.
What a WordPress backup actually contains
WordPress.org’s backup guide is blunt about it: back up both the database and the files, because “you need both to be able to fully restore a typical WordPress site” (developer.wordpress.org, WordPress Backups).
| Part | What lives there | How you get it |
|---|---|---|
| Database | Posts, pages, comments, users, site and plugin settings, menus | An export file (.sql, often compressed as .gz or .bz2) |
| Files | WordPress core, themes, plugins, uploaded media, wp-config.php, .htaccess |
A copy of the WordPress folder |
The handbook points out the database is stored separately from the files, so downloading the WordPress folder does not include it. And a database export does not include your images. Each half is useless for a full restore without the other.
The handbook also gives an order. When you back up: database first, then files, kept together as one set. When you restore: files first, then database.
Four ways to back up, and when each makes sense
The shape of the choice:
host backups (easy, but on someone else’s terms) → a backup plugin (scheduled, in your control) → manual SFTP + database export (slow, but you understand every byte) → command line (fast, for big sites)
My stance: use a scheduled method you do not have to remember, and do a manual one now and then to prove the scheduled one works. WordPress.org recommends the same check.
1. Your host’s backups
Many hosts run backups for you. Ask three questions: how often, how many copies they keep, and whether you can download one yourself. A host backup you cannot download is the host’s backup, not yours. If the host goes away or suspends the account, it goes with them.
2. A backup plugin
The WordPress.org plugin directory has plugins that run scheduled backups. Whatever you pick, check four things in its settings: that it includes the database, that it includes uploads, where it sends the files (off the server is the point), and how many old copies it keeps. I am not naming one here; any of the established ones work if those four settings are right.
3. Manual: files by SFTP, database by phpMyAdmin
This is the method worth knowing even if you never use it, because it shows you what a backup really is.
- Export the database. Log in to phpMyAdmin from your hosting panel, select your WordPress database, open the Export tab. The handbook describes two modes: Quick exports everything uncompressed; Custom lets you pick only the tables with your WordPress prefix (useful if the database is shared), compress the output, and add
DROP TABLEstatements so the file can later overwrite existing tables cleanly. Choose SQL as the format (developer.wordpress.org, Backing Up Your Database). - Download the files. Connect by SFTP and copy the whole WordPress folder to your computer, including
wp-config.phpand any.htaccessfiles. - Put both in one dated folder. Something like
2026-10-19-full, zipped. A database from Tuesday and files from Friday are not one backup.
4. Command line, for large sites
The handbook says phpMyAdmin cannot handle large databases and points to the MySQL/MariaDB command line instead. A typical export:
mysqldump --add-drop-table -h DB_HOST -u DB_USER -p DB_NAME | gzip > site-db.sql.gzReplace the capitals with the values from your wp-config.php. The handbook notes gzip is faster on big files and bzip2 compresses smaller.
How often, and how many copies
WordPress.org’s answer to “how often should you back up?” is practical (WordPress Backups):
- weekly for smaller sites that change rarely;
- daily for active sites;
- always before an upgrade or a move to a new host;
- keep at least three to five recent backups;
- store copies in different places: the hosting server, cloud storage and your own computer.
The hardening guide adds one more point: keep several dated snapshots, so that if a compromise is discovered late you can still roll back to a copy from before it started. A backup made the day after a hack is a copy of the hack. It also suggests protecting the backups themselves: encrypt them, keep an independent checksum of each file, or write them to read-only media, so you can tell later that nobody has tampered with them (developer.wordpress.org, Hardening WordPress). Our guide on how to secure a WordPress site covers where backups fit with everything else.
A worked example
No client case studies exist on this site yet, so this one is hypothetical.
Say you run a small WordPress blog on shared hosting with no backup at all. A sensible setup, in the order my agent would build it:
manual export today → install a scheduled backup plugin → database daily, files weekly → send to cloud storage, not the server → keep several weeks of copies → once a quarter, restore the latest one to a test site
The first manual export is the important one. It is the only backup you know is complete, because you made it with your own hands. The quarterly test restore is the second most important, because it is the only way to learn the plugin has been skipping the database since an update.
When you need to put a backup back, follow our guide on how to restore website from backup; it covers the file-then-database order and the usual errors.
Common mistakes
- Backing up only the files. Your content is in the database.
- Backing up only the database. Your images and theme are in the files.
- Keeping every copy on the same server. One failure, one hack, or one suspended account takes the site and its backups together.
- Keeping only one copy. If the newest backup is broken or infected, there is nothing older to go to.
- Never testing. A backup is only proven by a restore.
- Forgetting
wp-config.php. It holds the database connection and secret keys. Keep it, and keep it private: it contains passwords.
And if there is no backup at all?
It happens: the host shut down, the account was deleted, the backups were on the same server. The site may still exist in public web archives such as the Internet Archive’s Wayback Machine. Wayback Press can scan an archived domain for free and show a preview of the old design, URL structure and a few sample pages, so you can see what is recoverable before deciding anything. If you then want to recover deleted website files, we rebuild the site from those snapshots as static HTML or editable WordPress, with an AI check of every page and a human review before delivery. You need to hold the rights to the content you restore. Wayback Press is not affiliated with the Internet Archive.
That is a rescue, though, not a backup plan. An archive keeps the pages it happened to crawl; your backup keeps everything.
The email said “Backup completed.” Open the zip once and check that it was telling the truth.