WordPress
A WordPress backup needs files and database
Back up WordPress uploads, themes, plugins, configuration and database with matched recovery points.
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
The database contains posts, settings and much plugin state; wp-content holds uploads, themes and plugins. A useful recovery captures both at compatible points, protects credentials, lives off the server and is restored regularly in isolation.
What this means in plain English
WordPress stores posts, users and settings in the database. Uploaded images, themes and plugins live in files, mainly under wp-content. A complete recovery needs both parts from compatible points in time.
Keep copies away from the live hosting account and retain several dates. Protect them because they may contain customer details and passwords. Restore regularly to a private test address and check the site as a user.
What must be restored together?
| Database | Content, users, options and plugin tables |
|---|---|
| Files | wp-content plus required configuration/custom files |
| Recovery | Matched copy tested on a separate URL |
A simple example
A backup contains the database but not uploads. The restored site has every post title, yet all photographs are missing. Another backup has files but an old database, so recent orders vanish. A matched files-and-database restore avoids both failures.
What to do, step by step
1. Define acceptable data loss and restore time.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on database: content, users, options and plugin tables. Write the result down so you can compare it later.
2. Capture database consistently and files completely.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Encrypt and retain off-host generations.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Test login, media, links and forms after restore.
Finish by checking the result against recovery: matched copy tested on a separate url. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Include unusual custom folders and required configuration in the inventory. “Back up wp-content” may not cover a site that stores data somewhere else.
Common mistakes and how to avoid them
Backing up uploads only.
This gives a misleading or unsafe result because it leaves out database. A better approach is to define acceptable data loss and restore time, then check the result before making the change permanent.
Keeping one backup on the live account.
This gives a misleading or unsafe result because it leaves out files. A better approach is to capture database consistently and files completely, then check the result before making the change permanent.
Restoring over production as the first test.
This gives a misleading or unsafe result because it leaves out recovery. A better approach is to encrypt and retain off-host generations, then check the result before making the change permanent.
Words explained
- WordPress
- A content management system that lets people edit pages and posts through an administration screen.
- plugin
- An add-on that gives WordPress extra features. Every plugin also adds code that must be updated and checked.
- theme
- The code and design files that control how a WordPress site looks.
Quick checklist
- Define acceptable data loss and restore time.
- Capture database consistently and files completely.
- Encrypt and retain off-host generations.
- Test login, media, links and forms after restore.
Common questions
What is the simple answer?
The database contains posts, settings and much plugin state; wp-content holds uploads, themes and plugins. A useful recovery captures both at compatible points, protects credentials, lives off the server and is restored regularly in isolation.
What should I check first?
Start with database: content, users, options and plugin tables. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Define acceptable data loss and restore time. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Backing up uploads only. Avoiding that one mistake makes the rest of the comparison much more trustworthy.