Check that a WordPress backup includes files and database Print

Quick answer

A usable WordPress backup needs the website files and the matching database from an appropriate recovery point. A backup missing its database can contain images and code while lacking posts, users, settings and orders. Keep the copies protected and confirm what can be recovered before replacing the live site.

Identify the website and matching database

1. Open the correct hosting service and confirm its document root in cPanel > Domains. Several WordPress installations can share one hosting account, so public_html is not sufficient identification by itself.
2. In the intended installation's private configuration, identify the database used by that site. WordPress commonly records its database name as DB_NAME in wp-config.php. Inspect it only with authorized access; do not paste the file, password or security keys into a ticket or AI chat. An account prefix can form part of the database name.
3. Check the backup tool's scope and exclusions. Preserve required site files, including uploads, plugins, themes, configuration and any relevant root files or hidden access rules. A copy of wp-content alone is not a complete account or application backup.
4. Confirm the SQL export belongs to the identified database and that the file archive belongs to the same website and intended recovery point. A full-account backup can contain multiple sites or databases; a home-directory-only archive is not proof of a database export.

Create and protect the required copies

Use the cPanel backup guide for full or supported partial backup controls. Download the completed files securely, keep an independent protected copy and record the website, backup time/time zone, tool, contents and exclusions. Keep SQL dumps, configuration and archives outside public web access.

Verify before a recovery

Check that the archives open, contain the expected files and include the intended readable database export. Record whether a live file capture and SQL export represent one consistent point in time. A busy store or membership site needs a plan to preserve newer orders, inquiries, registrations and external payment activity. Plan that reconciliation before replacing a database.

Arrange an authorized isolated recovery verification before relying on the backup for a major change. Keep outbound messages, scheduled jobs, payments and live integrations disabled in an isolated copy. An archive listing alone does not prove that the application can run.

Backup missing database or restore reports missing tables

Preserve the existing backup and error. Confirm the selected database, export scope, compression format and whether the backup job completed. Do not import an unrelated SQL file or create an empty replacement database over the current site. Contact support with the affected domain, tool, backup time, expected components and redacted error. Do not send credentials or full customer records in the ticket body.

Related help

• How to backup your website in cPanel
• Find the correct document root before an AI tool uploads files
• Test a website restore without replacing the live site
• Preserve new orders and inquiries when planning a restore
• Store website backups outside public web access
• Send a website support request with useful troubleshooting details

Official references

• WordPress backup requirements
• cPanel Backup Wizard

Content and source review: November 1, 2026. Recovery scope and available tools depend on the service and application.