Use selective restore when the damaged component, healthy backup and dependencies are known. Stop before an unexplained table selection; smaller scope does not guarantee safe recovery.
BlogVault supports selecting files and database tables for recovery. Selected live content is overwritten; choosing less does not remove that risk. See its selective restore instructions.
The practical question is therefore: which older files or tables are needed to repair this problem, and which newer live changes must survive? This guide explains that decision using official documentation and editorial analysis. It does not report a hands-on restore test.
When a selective restore makes sense
It is a good fit for a clearly identified change: an accidentally edited theme file, a damaged plugin folder, or a database problem whose affected tables and dependencies are understood. You need a healthy backup from before the damage and access to the correct site’s restore controls.
It is a poor first move when you do not know what changed, cannot distinguish a plugin’s files from its stored settings, or suspect an intrusion. Restoring an old component may leave the cause in place. For an apparent compromise, follow the first steps for a hacked WordPress site before treating recovery as an ordinary update rollback.
A concrete example: roll back a plugin while keeping today’s article
Imagine a publishing site where a plugin update at 10:00 breaks a page. An editor publishes an article at 10:30. You have a healthy backup from 09:00. A full database rollback to 09:00 could remove the later article. A plugin-file rollback may repair the error while leaving the database alone, provided the older plugin remains compatible with the current database.
BlogVault’s plugin restore guide describes selecting a particular plugin folder and excluding database tables. It also warns that restoring the database can remove data added after the backup. That supports a file-only option; it does not prove that every plugin can be safely downgraded.
Before using that option, read the plugin’s update notes. If the update migrated its database structure or changed stored settings, ask the developer which recovery method preserves compatibility. A file rollback that produces a different error is not a successful repair.
Choose the scope before opening the final restore screen
| Problem | Scope to investigate | What to preserve |
|---|---|---|
| One edited theme file breaks a layout | The known file and any required companion assets | Other theme edits and current content |
| A plugin update causes a reproducible error | The plugin folder, after checking downgrade compatibility | Current posts, users and unrelated settings |
| An uploaded image was deleted | The missing file and the related Media Library record if needed | Newer uploads and their records |
| A page’s content was changed | Revision history first; database recovery only if necessary | Other pages saved since the backup |
| A plugin’s settings are corrupt | Its documented storage and related records | Unrelated settings that share the same table |
This table is a troubleshooting starting point, not an automatic selection recipe. A folder can contain many files; a table can hold records used by several features. Write down the exact intended change in one sentence. If your selection covers much more than that sentence, investigate before proceeding.
Prepare a recovery path that includes the current state
- Confirm the site. Read the domain in the dashboard, especially if you manage several WordPress installations. Do not identify a site only by a similar title or logo.
- Record the timeline. Note the time of the damaging change, the chosen healthy backup and important activity since then. Include edits, registrations and form entries, not just orders.
- Keep a copy of the current state. It may contain valuable new content even though one feature is broken. Preserve the healthy older backup separately.
- Stop competing changes. Avoid another update or restore running while you are deciding the scope. Tell other editors which parts should remain untouched during recovery.
- Write an acceptance check. Name the broken action and the newer record that must survive. Both need checking after recovery.
For an on-demand recovery point, BlogVault documents Backups → Backup Now, followed by a progress screen. Starting the task is not proof it has finished; inspect its completion and coverage before relying on it. See the manual backup instructions. For the wider preparation, use our WordPress backup and restore checklist.
Review the BlogVault selection carefully
The documented selective workflow is:
- Open the intended site, then its Backups section and Restore controls.
- Use Select beside Restore Files to choose the required files or folders, then confirm that selection.
- Review Restore Tables separately. Choose only tables required for the repair; do not assume that a file selection also excludes the database.
- Continue to the summary and check the backup version, destination and both scopes.
- Only when the summary matches the recovery plan, start the restore and monitor the task.
BlogVault warns that a started restore cannot be interrupted. Confirm final completion in the task details. If the controls differ from the documentation, resolve the mismatch before initiating.
Database selection is the difficult part
WordPress separates files from database content. Its database backup documentation explains that a database copy covers items such as posts, comments and settings, but not themes, plugins or uploaded files. Recovering one side alone may leave an incomplete feature.
The WordPress database schema also shows separate tables for posts, post metadata, terms and other records. A page can depend on more than its main text. Plugins may add their own storage, and a site’s table prefix need not be wp_. Do not choose a table simply because its name looks familiar.
For example, restoring a whole table to recover one page can replace other pages or settings changed since the backup. A table-level selector is not a promise to recover only one desired record. If you cannot list the affected records and dependencies, prefer a page revision, a plugin’s own recovery tool, or specialist help with a verified copy of the database.
Test the backup, then verify the live repair
BlogVault provides Test Restore from backup details. Its test restore documentation describes choosing a backup and PHP version, reviewing the summary and creating a test environment without changing live. Use it to inspect the candidate backup and reproduce the previously working action.
A healthy old copy is useful evidence, but it does not prove that mixing old plugin files with today’s live database will work. Your final check must cover the combination you actually restore.
- Repeat the previously failing action as a visitor and, where relevant, as an administrator.
- Confirm the expected plugin or theme version and inspect related error logs.
- Open the newer article, account or transaction record that your plan required preserving.
- Check representative images and links, then clear only the relevant caches if stale output remains.
- Keep both recovery points until the site has passed its next meaningful publishing or business cycle.
If the result is wrong
The same error remains: stop repeating the identical restore. Check whether the cause is a setting, a dependency, cached output or something outside the selected files. Our plugin conflict guide helps narrow an unclear failure.
New content is missing: record what was overwritten and compare the selected tables with the recovery plan. Preserve the current evidence before another operation. The pre-restore backup may be needed to recover the newer data; another broad rollback can make the timeline harder to untangle.
The task fails or stalls: inspect the task details, affected site and available connection information before starting another job. Give support the relevant task reference and symptoms, without sharing passwords in public tickets.
Other recovery options and the final decision
A hosting restore point, WordPress revision or independently stored file copy may already solve a narrow problem. Compare the available selection and restore controls before buying another service. A database-sensitive rollback needs a person who understands the site’s storage even when the restore button is easy to use.
Go ahead when the correct healthy backup, exact scope, dependency checks and verification plan are clear. Stop when the only justification is that a smaller selection feels safer. BlogVault is worth considering when reviewable file and table recovery fits your workflow; inspect its current plans and supported restore features before choosing it.
Sources and verification
Editorial review 2026-10-19. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- BlogVault: selectively restore files and tablesChecked Separate file and table selectors, summary, initiation overwrite and no-interruption warning, completed task review.
Limits: Documents the workflow, not universal plugin downgrade compatibility or row-level recovery. Dashboard control placement may change. - BlogVault: restore a plugin from an older backupChecked Selecting one plugin folder and excluding tables; warning about losing database changes since the backup.
Limits: Does not establish that a particular plugin can run against the newer database after a file rollback. - BlogVault: start a backup manuallyChecked Backup Now on-demand workflow and completion monitoring.
Limits: Initiation is not completion; coverage and usable recovery points still need checking. - WordPress: backing up your databaseChecked Database contains posts, comments and settings; file backup is separate.
Limits: General WordPress guidance, not a map of any third-party plugin storage. - WordPress: database schemaChecked Separate posts, postmeta, taxonomy and other core tables illustrate dependencies.
Limits: Not a per-site inventory; plugins and custom prefixes require local identification. - BlogVault: validate or test restore backupsChecked Test Restore creates a test environment from a chosen backup and PHP version without changing live.
Limits: A healthy old copy does not validate every mix of older files and newer live database data.