Files-Only vs Database-Only vs Full WordPress Restore: Which Should You Choose?

Most WordPress restore mistakes happen before anyone clicks the restore button. The site owner sees an error, picks the newest backup, runs a full restore, and only later realizes that the restore fixed one problem while replacing something that should have been kept: a new order, a form submission, a page edit, a user account, a media upload, a plugin setting, or a security clue that would have helped explain the incident.

WordPress recovery is not just a question of "do we have a backup?" A better question is: which part of the site needs to go back in time? Sometimes the right answer is only the files. Sometimes it is only the database. Sometimes it is the entire site. The difference matters because WordPress stores different kinds of information in different places, and each restore type changes a different part of the site.

This guide explains how to choose between a files-only restore, a database-only restore, and a full WordPress restore. It is written for site owners, freelancers, agencies, and support teams who want practical recovery decisions, not vague backup theory. We will walk through the main restore types, what each one changes, what each one can accidentally overwrite, and how to apply the right restore type to common real-world scenarios like deleted media, bad plugin updates, hacked files, accidental page deletion, and WooCommerce order concerns.

Quick Answer: Which Restore Type Should You Choose?

Use a files-only restore when the problem lives in WordPress files: themes, plugins, uploads, WordPress core files, custom code, or damaged assets. Use a database-only restore when the problem lives in stored site data: posts, pages, settings, users, orders, comments, menus, product records, form entries, and plugin tables. Use a full restore when both files and database need to return to the same known good point, or when the site is so damaged that separating the problem is slower or riskier than restoring everything.

That short answer is useful, but it is not enough. The hard part is identifying where the problem actually lives. A deleted image from the media library might involve both a file on disk and a database attachment record. A bad plugin update may be only a changed plugin folder, or it may also have run a database migration. A hacked site might have malicious PHP files, injected database content, or both. A WooCommerce restore can make the store work again while wiping orders placed after the backup point. The correct restore decision depends on the type of incident and what changed since the backup you plan to use.

How WordPress Stores Data: Files vs Database

To choose the right restore type, you need a simple mental model of WordPress. A WordPress site is not one single object. It is a combination of files and database records working together. The browser does not load your site from a folder full of finished HTML pages. WordPress runs PHP files, queries the database, loads theme and plugin code, and assembles the page dynamically.

The filesystem usually contains WordPress core files, themes, plugins, uploads, custom code, cache files, logs, and sometimes configuration files. The database usually contains posts, pages, users, options, menus, widgets, comments, product data, order data, plugin settings, page builder layouts, form entries, SEO metadata, membership records, and other application data. Some features depend on both. For example, a media library image has a physical file in uploads and a database attachment record that tells WordPress the title, URL, sizes, metadata, and where that image is used.

This split is why the restore choice matters. Replacing files does not automatically recover a deleted page, because pages are database records. Replacing the database does not automatically fix a corrupted plugin file, because plugin PHP code lives in the filesystem. A full restore handles both layers, but it may roll the whole site back farther than necessary.

There are exceptions because plugins can store data in custom places, hosts can add special directories, and some sites write generated files outside the default WordPress directories. Still, the files-versus-database model is accurate enough to guide most recovery decisions. Before restoring, identify which layer contains the broken or missing item.

What Is a Files-Only WordPress Restore?

A files-only restore replaces the site files from a backup while leaving the current database in place. Depending on the backup tool and configuration, this may include WordPress core, plugins, themes, uploads, custom directories, configuration files, or selected folders. The important point is that the database stays current.

This makes files-only restore especially useful when the site is active and database changes matter. If customers are placing orders, users are registering, forms are being submitted, editors are updating pages, or membership data is changing, preserving the current database can prevent avoidable data loss. A files-only restore can roll back a broken plugin folder without removing orders that arrived after the backup point.

Files-only restore is also one of the most practical recovery tools after a bad code change. WordPress problems often start when a plugin update, theme edit, custom snippet, or file upload introduces incompatible code. The database may be perfectly healthy. In that case, replacing the affected files with the last working versions is cleaner than rolling back everything.

Good reasons to choose files-only restore

• A plugin update caused a fatal error, white screen, layout break, or admin access problem.
• A theme update broke templates, styling, blocks, menus, or checkout display.
• A developer edited PHP, JavaScript, CSS, or template files and needs to roll back the file changes.
• Upload files are missing, corrupted, or accidentally removed from the server.
• Malware appears to be limited to PHP files, injected scripts in files, or unexpected files in plugin/theme directories.
• WordPress core files were modified, partially deleted, or corrupted.
• The database contains recent business data you do not want to overwrite.

What files-only restore will not fix

A files-only restore will not restore deleted pages, posts, products, orders, users, comments, plugin settings, menus, widgets, or page builder layouts if those items are missing from the database. It also will not undo database changes made by a plugin update. If a plugin update ran a schema migration, changed options, or modified stored data, replacing the plugin files may not fully reverse the issue.

The safest use of files-only restore is when you can clearly identify that the problem started in files. If you are unsure, inspect error logs, recent changes, plugin update history, file modification dates, and the symptoms. A PHP fatal error after a plugin update strongly points to files. Missing content inside wp-admin usually points to the database. Broken front-end styling could be either a theme file problem, a cache issue, or a database-stored page builder setting, so check before restoring.

What Is a Database-Only WordPress Restore?

A database-only restore replaces the WordPress database from a backup while leaving the current files in place. This restores stored content and settings to a previous point in time. It can recover pages, posts, users, site options, menus, widgets, page builder records, plugin data, WooCommerce products and orders, form entries, comments, and other information stored in database tables.

Database-only restore is powerful because WordPress stores so much site behavior in the database. It is also risky for the same reason. On a quiet brochure site, rolling the database back to yesterday may be acceptable. On an ecommerce store, membership site, learning management site, community site, or high-traffic lead generation site, a database restore can overwrite valuable activity that happened after the backup point.

Good reasons to choose database-only restore

• A page, post, product, category, menu, widget, or reusable block was deleted and cannot be recovered from trash or revisions.
• A bulk edit damaged content, SEO metadata, product pricing, taxonomies, or page builder layouts.
• A plugin setting change broke site behavior, and the setting is stored in the database.
• Database tables are corrupted, missing, or damaged.
• Malware or spam was injected into posts, options, redirects, user records, or plugin tables.
• An import, migration, sync job, or automation changed stored content incorrectly.
• The files are known to be healthy and do not need to change.

What database-only restore can overwrite

A database-only restore can overwrite anything created after the backup point if it lives in the database. That includes orders, subscriptions, refunds, customer accounts, product changes, inventory adjustments, comments, form submissions, appointment bookings, membership changes, course progress, page edits, menu updates, plugin settings, redirects, coupons, discount rules, and user roles. This is why you should never treat a database restore as a harmless action on an active site.

Before a database restore, decide whether you can accept the rollback. If not, you need a more careful recovery path. Options may include restoring to staging first, exporting specific records from the current database, recovering individual tables, manually recreating a page from backup content, preserving new orders, or performing a selective merge. Selective database merging can be complex and should be handled carefully, especially on WooCommerce and membership sites where records are related across multiple tables.

What Is a Full WordPress Restore?

A full WordPress restore replaces both the files and the database from the chosen backup point. It is the most complete restore type. If the site needs to return to exactly how it looked and behaved at a known time, a full restore is the closest match.

Full restore is often the right choice after a broad failure. If a deployment changed plugin files, theme files, uploaded assets, database settings, custom tables, and page builder content, trying to repair one layer at a time may take too long. If a server is lost and the site needs to be rebuilt on a clean host, both files and database are needed. If a hack touched both files and database content, both layers must be cleaned or restored.

The tradeoff is disruption. A full restore rolls back the entire backed-up site to the backup time. If you restore from last night, anything created this morning may disappear unless preserved separately. This may be fine for a low-change brochure site. It can be unacceptable for a store, booking site, membership site, community, online course platform, or client site with active editors.

Good reasons to choose full restore

• The site is broken across both files and database, and a clean matching point is available.
• A failed migration or deployment changed too many layers to repair confidently.
• A hosting incident or server loss requires rebuilding the complete site.
• The damage boundary is unclear and fast recovery is more important than preserving every newer change.
• A malware incident affected both files and database, and the selected backup is known to be clean.
• You are restoring to a staging environment for investigation or comparison.

When full restore is too heavy

A full restore is often too heavy when the problem is narrow. If one plugin update broke the site, replacing the entire database may create unnecessary data loss. If one page was deleted, replacing every file on the server does not help. If one image file is missing, restoring the whole site may be excessive. The fastest-looking option can become the slowest option if it creates a second cleanup project.

A Practical Restore Decision Framework

When a site breaks, slow down enough to answer five questions. These questions turn the restore decision from a guess into a controlled action.

1. What changed right before the problem?

Look for recent plugin updates, theme updates, WordPress core updates, code deploys, imports, content edits, user role changes, malware alerts, server changes, PHP version changes, cron jobs, cache purges, and hosting changes. The most recent change is not always the cause, but it is the first clue. If the problem appeared immediately after a plugin update, a files-only rollback is more likely. If the problem appeared after a bulk content import, a database recovery is more likely.

2. Which layer contains the broken item?

Ask whether the missing or broken object is a file, a database record, or both. Plugin code lives in files. Plugin settings usually live in the database. Uploaded images live as files, but the media library listing lives in the database. Pages and posts live in the database. Theme templates live in files, but theme customizer settings usually live in the database.

3. What has changed since the backup point?

This is the question that prevents accidental data loss. A backup from six hours ago may be safe for a brochure site with no edits today. The same backup may be dangerous for a WooCommerce store that received twenty orders, three refunds, two new customer registrations, and inventory changes. The more new data exists after the backup point, the more cautious you should be with database and full restores.

4. Can you test the restore somewhere else first?

Whenever possible, restore to staging or a temporary environment before touching production. A staging restore can confirm that the selected backup is usable, the issue is fixed, and no obvious data is missing. This is especially useful for database-only and full restores because they are harder to undo cleanly once applied to production.

5. What is the least destructive fix that meets the recovery goal?

If you can fix a file issue with files-only restore, do that instead of a full restore. If you can recover one page from revisions or trash, do that instead of restoring the whole database. If the site is compromised and you cannot trust the current files or database, a broader restore plus cleanup may be justified. The goal is not always the smallest restore; the goal is the smallest restore that actually solves the incident safely.

WordPress Restore Scenario Table

The following table gives a practical starting point. It is not a substitute for inspection, but it helps you avoid the most common mismatches.

Scenario: Deleted Media or Broken Images

Media recovery is a good example of why "files or database?" matters. WordPress media has two sides. The physical image, PDF, video, or document lives in the uploads folder. The media library entry lives in the database as an attachment record with metadata. If only one side is missing, the restore should target that side.

If an image still appears in the media library but renders as a broken image on the front end, the attachment record may still exist while the physical file is missing. In that case, restoring uploads files from the right backup point may be enough. A files-only restore for the uploads directory can replace the missing original and generated image sizes without rolling back the database.

If the media item is gone from the media library entirely, the database attachment record may have been deleted. Restoring files alone may place the image back on the server, but WordPress will not automatically know that it belongs in the media library. You may need a database restore, a selective attachment recovery, or manual re-upload. If the image is used in a page builder layout, the page content may still reference an old URL or attachment ID, so test the affected pages after recovery.

Be careful with full restores for media issues. If only a few images are missing, a full restore may replace recent content and orders unnecessarily. Start by identifying whether the file, the attachment record, or both are missing. Then choose the narrowest restore that fixes the real problem.

Scenario: Bad Plugin Update

A bad plugin update is one of the clearest cases for considering a files-only restore first. Plugin code lives in the filesystem, usually under `wp-content/plugins/`. If the update introduced incompatible PHP code, missing files, changed assets, or a fatal error, replacing the plugin folder with the previous working version may bring the site back without touching the database.

This matters because the database may have continued to receive valuable data after the update. A full restore from before the update might bring the site online, but it may also remove recent orders, form submissions, comments, user registrations, or page edits. A files-only rollback is usually safer when the failure is truly code-based.

The exception is a plugin update that modifies the database. Many plugins run database migrations when updated. They may add tables, change table schemas, update option values, migrate settings, rebuild indexes, or rewrite records. If the plugin update changed the database and the older plugin files cannot work with the newer database state, a files-only restore might create a version mismatch. In that case, you may need the plugin vendor's rollback instructions, a database restore, or a full restore to a matched file and database point.

Bad plugin update recovery sequence

• Record the current error and the plugin version that was installed before and after the update.
• Disable the plugin if needed to regain wp-admin access.
• Check whether the plugin documentation mentions database migrations or rollback limits.
• Restore only the plugin files or the affected filesystem area if the database is likely healthy.
• Test front end, wp-admin, logs, scheduled tasks, and any feature the plugin controls.
• If database mismatch errors remain, stop and reassess instead of repeatedly restoring files.

Scenario: Hacked Files, Malware, or Suspicious Redirects

Security incidents require more caution than ordinary breakage. A restore can remove visible malware, but it does not automatically close the entry point. If you restore infected files from a backup, the problem remains. If you restore clean files but leave a malicious admin user, stolen password, vulnerable plugin, or injected database record in place, the site may be reinfected.

Use files-only restore when the compromise is clearly limited to files and you have a clean backup from before the infection. Examples include unexpected PHP files in uploads, modified theme files, injected scripts in plugin files, or changed WordPress core files. After restoring clean files, update vulnerable components, rotate credentials, check file permissions, review admin users, and scan the database.

Use database-only recovery or cleanup when the hack lives in database content. Examples include spam links in posts, malicious JavaScript in options, fake admin users, injected redirects, altered site URLs, changed plugin settings, or malicious records in custom tables. A files-only restore will not remove those database entries.

Use full restore when both layers are compromised or when you cannot confidently separate clean from infected. Restore to a clean point, patch the vulnerability, rotate credentials, and scan again. On business-critical sites, it can be better to restore to staging first, compare, clean, and then deploy the clean result instead of rushing a production restore without understanding the compromise.

Scenario: Accidental Page Deletion or Bad Content Edit

Pages and posts are database records. If someone deletes a page, overwrites a landing page, changes a page builder layout, removes a menu, or damages reusable blocks, a files-only restore will usually not help. The content is not stored as a finished file in the theme folder. It is stored in database tables.

Before restoring the database, check the low-risk recovery options. WordPress may have the page in trash. Revisions may contain the previous content. Autosaves may help. A page builder may have its own revision system. Your SEO tool, cache, CDN, staging site, or backup preview may have a copy of the text. Manual reconstruction may be faster and safer than a full database restore if only one page is affected.

If the page is business-critical and cannot be recovered through trash or revisions, a database restore may be needed. The safest pattern is often to restore the backup to staging, copy the lost content or page structure from staging, and manually rebuild or import it into production. This avoids overwriting production database activity. If you must restore the production database, identify everything created after the backup point and decide whether it needs to be preserved.

When database-only restore makes sense for content

• The content loss affects many pages or settings, making manual reconstruction impractical.
• The backup point is recent and little or no important database activity happened afterward.
• The site is not ecommerce, membership, booking, or community-driven, reducing rollback risk.
• You have approval to overwrite database changes after the backup point.
• You can export or preserve newer records before the restore.

Scenario: WooCommerce Order Concerns

WooCommerce changes the restore calculation because orders, customers, refunds, subscriptions, inventory, product edits, coupon usage, and tax settings are database-sensitive. A full restore or database-only restore can roll those records back. That can create customer service problems, accounting gaps, fulfillment errors, subscription confusion, and inventory mismatches.

For WooCommerce, prefer files-only restore whenever the problem is file-based. If a plugin update breaks checkout styling, a theme template causes errors, or a custom code change breaks the cart, do not restore the database unless you have evidence that database records are damaged. Preserving current orders is usually more important than taking the broadest restore path.

If the problem is database-based, move slowly. Maybe product prices were bulk edited incorrectly. Maybe orders are missing. Maybe subscription records are damaged. Maybe checkout settings were changed. In those cases, a database restore may be necessary, but it should be planned. Check the backup timestamp, list all orders after that timestamp, export order data if possible, note refunds and payment status, and decide how reconciliation will happen after the restore.

For stores, approval matters. If you are an agency or freelancer, do not quietly perform a database or full restore that may overwrite order data. Explain the backup timestamp, likely data impact, expected downtime, and reconciliation plan. Record the client's approval before proceeding.

The Pre-Restore Checklist

A good restore process starts with a pause. The site may be broken, but a rushed restore can make the situation worse. Before restoring, collect enough information to choose the right path and preserve important data.

• Identify the incident: what is broken, who reported it, when it started, and what changed immediately before it.
• Record the current state: screenshots, error messages, URLs, logs, plugin versions, and whether wp-admin is accessible.
• Confirm backup availability: date, time, scope, storage location, and whether files and database are both present.
• Check recent activity: orders, form submissions, user registrations, content edits, comments, bookings, subscriptions, imports, and scheduled jobs since the backup point.
• Choose the restore scope: files-only, database-only, full, or a staged/manual recovery.
• Decide whether to test on staging first, especially for database and full restores.
• Preserve current data if needed: export orders, save form entries, copy content, download logs, or snapshot the current site.
• Pause risky activity if appropriate: maintenance mode, checkout notice, plugin auto-updates, imports, cron jobs, or editor activity.
• Get approval when the restore can affect revenue, orders, users, or recent client edits.

This checklist is not bureaucracy. It protects you from making a technically successful restore that creates business damage. The best restore is not only the one that makes the front end load. It is the one that brings the site back without losing the data the client still needs.

Post-Restore Checks: Prove the Site Is Actually Healthy

After the restore, do not assume the site is fixed because the homepage loads. Test the parts of the site that matter most. A restore can fix one visible symptom while leaving broken background jobs, stale caches, missing media sizes, plugin mismatch warnings, or checkout errors.

• Load the homepage, key landing pages, blog posts, product pages, and any affected URLs.
• Log in to wp-admin and confirm the dashboard, plugins page, media library, users, and settings screens load normally.
• Check the specific issue that triggered the restore and verify it is resolved.
• Review error logs after the restore for new fatal errors, warnings, or database errors.
• Clear caches carefully: WordPress cache, object cache, CDN cache, browser cache, and host cache if needed.
• Test forms, search, navigation menus, media, checkout, account login, and transactional emails.
• For WooCommerce, place a test order if appropriate and verify recent real orders are still present.
• Check SEO-sensitive settings: permalinks, redirects, canonical settings, robots settings, and sitemap output.
• Start a fresh backup after the site is confirmed healthy, so the recovered state becomes a new recovery point.

For agencies, this is also where reporting helps. Tell the client what happened, what was restored, which backup point was used, what data was preserved, what was tested, and what follow-up actions are recommended. A clear restore report turns an emergency into evidence that the site is being managed professionally.

Common Restore Mistakes to Avoid

The most common mistake is choosing a full restore because it feels decisive. Full restore is sometimes correct, but it should not be the default. If a narrow restore solves the problem, use it. The second common mistake is restoring the database on a busy site without checking what happened after the backup point. This is how stores lose orders and lead generation sites lose form submissions.

Another mistake is ignoring version compatibility. Files and database often evolve together. If you restore old plugin files against a newer database migration, the plugin may fail. If you restore an old database while leaving newer plugin files in place, the plugin may expect tables or settings that no longer exist. Full restore avoids some version mismatch risk by returning both layers to the same time, but it increases data rollback risk. This is why staging tests are so valuable.

Security restores have their own mistake pattern: restoring visible files but leaving the vulnerability open. After malware, do not stop at "the warning disappeared." Find the likely entry point, update vulnerable software, remove abandoned users, rotate credentials, check database records, and confirm the clean state with another scan. Otherwise the same issue can return.

Finally, avoid restoring without a current snapshot. Even when the site is broken, the current state may contain important data. If the restore goes poorly or you discover that the chosen backup was not the right one, having a pre-restore snapshot gives you an escape route.

FAQ

Is files-only restore safer than full restore?

It is safer when the problem is limited to files because it preserves the current database. That means recent orders, form submissions, users, comments, and content edits are not rolled back. It is not safer if the problem is actually in the database or if old files are incompatible with newer database changes.

Can I restore only one plugin or one folder?

That depends on the backup and restore tool. Some tools allow targeted file restores, while others restore broad file groups. If targeted restore is available, it can be useful for plugin or theme rollbacks. Still check whether the plugin changed database settings during the update.

Can I recover one page without restoring the whole database?

Often yes. Check trash, revisions, autosaves, staging copies, page builder history, browser drafts, cached versions, or a backup restored to staging. Rebuilding one page manually from a backup copy may be safer than rolling the production database back.

What if I do not know whether the issue is files or database?

Start with diagnosis, not restore. Review recent changes, error logs, affected URLs, wp-admin behavior, file modification times, database errors, malware scan results, and plugin update history. If the damage boundary remains unclear and downtime is severe, restore to staging from candidate backups and compare before changing production.

Should I always use the newest backup?

No. Use the newest clean backup that predates the problem and includes the data you need. If the newest backup was created after the malware infection, bad import, or corrupted update, restoring it may reintroduce the same issue. Backup time matters, but clean state matters more.

How do MyWPBackups restore controls fit into this decision?

The restore controls are most useful when they match the incident. Files-only restore helps you recover themes, plugins, uploads, and other filesystem problems without rolling back the database. Database-only restore helps you recover content, settings, users, orders, and plugin records when the files are healthy. Full restore is available when the site needs both layers restored together. The decision should come from the incident, not from habit.

What should I do after a successful restore?

Test the site, confirm the original issue is fixed, check logs, clear caches, verify important workflows, review recent data, document what changed, and create a fresh backup. If the restore followed a security incident, also patch the vulnerability and rotate credentials.

Final Thoughts

The best WordPress restore choice is rarely "restore everything and hope." A files-only restore, database-only restore, and full restore each solve a different class of problem. The right choice depends on where the damage lives, what changed after the backup point, and how much data you can afford to roll back.

For simple file problems, files-only restore can be fast and low-risk. For content and settings problems, database-only restore can be the correct tool, but it deserves caution. For broad failures, migrations, and combined damage, full restore may be the cleanest route. The skill is knowing which recovery path fits the incident.

MyWPBackups is built around that practical reality: reliable off-site backups are only useful if you can restore the right part of the site at the right time. Before your next emergency, make sure your backups are complete, your restore options are understood, and your team knows when to use files-only, database-only, or full restore.