What belongs in a complete WordPress backup?

Start with files and the database

The database and files serve different purposes. Your posts, many settings and application records live in the database. Uploaded media and installed software live in the filesystem. Saving only one side can leave an incomplete recovery path.

Read your tool’s scope settings rather than assuming its default profile covers everything. Some tools split a backup into separate components. Others make a database-only copy, exclude large directories or require several incremental pieces.

• Identify the database export or provider-specific database component.
• Identify uploaded media and any offloaded media dependency.
• Check themes, plugins and custom code.
• Keep every component required by the provider’s restoration instructions.

Make exclusions deliberate

Caches and temporary files may be safe to regenerate. An uploads directory usually contains material you cannot reconstruct from a clean WordPress installation. A custom directory can matter even if the backup tool does not recognize its name.

Keep a short exclusions list with a reason beside each item. Review it when adding plugins, changing media storage or moving hosting. An exclusion that made sense last year may no longer be appropriate.

Do not judge completeness from archive size alone. Compression, media changes and different job scopes can change the size for legitimate reasons. An unexpected change is a prompt to inspect the job, not a verdict by itself.

Identify what lives outside WordPress

A working site can depend on DNS, email delivery, payment services, external media and scheduled tasks. Those services are not necessarily contained in a WordPress backup. You need a way to regain access and reconnect them.

Document the hosting environment and critical dependencies without placing passwords in a client report. Keep secrets in an appropriate secure store. Note who can authorize a domain change, reconnect a storage account or restore the database.

• Record the required PHP and database environment.
• Document external media and application integrations.
• Keep recovery access available to an authorized person.
• Separate secret credentials from shareable backup documentation.

Choose a recovery point that makes sense

Files and database records need to describe a usable point in the site’s history. For a busy shop or membership site, writes can continue during the backup. Ask how your provider handles that consistency and what changes might be lost when restoring an older copy.

Write down the acceptable loss window for the business. A brochure site updated weekly and a shop accepting orders every hour need different conversations. Backup frequency should follow the consequence of lost changes, not just the easiest default schedule.

The most convincing way to assess your recovery inventory is to use it in a separate restoration test and record the result. Keep the original backup until the test and retention decisions are complete.

Where BackupTool fits

BackupTool records the job information supplied by supported backup software. A reported size or successful result does not inspect your archive’s contents. Use monitoring alongside the scope settings and recovery instructions in the tool that creates the backup.