A website-folder copy is not a complete WordPress backup

Inventory the retained copy rather than the backup promise

Locate the actual retained backup and the record describing what its job captured. Record the site it belongs to, the backup reference and where an authorized person can retrieve it. A hosting plan that advertises backups is evidence of an offering, not proof that this account has a retrievable copy of the required age and scope.

Inspect the inventory or manifest where one exists. If it names only the website directory, database coverage is still unconfirmed. If it is a database export only, file coverage remains unconfirmed. If it is a managed snapshot whose contents are not visible, obtain the component scope for that specific snapshot instead of guessing from a label such as full backup.

A download completion notice, archive size or familiar filename cannot answer which components are inside. Classify the retained copy as files only, database only, both with documented coverage, or coverage unknown. That classification identifies the missing work without pretending to have demonstrated recovery.

Check database and file coverage separately

WordPress explains that files and the database are separate parts of the site. Its backup guidance includes themes, plugins, uploads and configuration among the files that need consideration. A copied theme can preserve appearance-related code while leaving the database absent; a database export can preserve database content while leaving required files absent.

For the database component, have the authorized maintainer identify which site database was captured and whether the backup includes the tables that the actual installation uses. Record any table exclusions or uncertainty about the installation covered. Do not assume an export belongs to the store merely because its filename contains the brand name.

For the file component, compare the backup inventory with the installed site’s required themes, plugins, uploads, configuration and custom files. Name exclusions explicitly. If the store relies on media, configuration or a service outside that file set, record the dependency and where its recovery information is held. This is an inventory question; it does not establish that WordPress’s backup includes an external service’s data or payment-provider records.

Put dates and exclusions next to the coverage claim

Keep the capture time for each component, including the time zone where recorded. The time a file was downloaded may be later than the time its contents were captured. A newly downloaded archive can therefore contain an older copy of the site.

WordPress’s guidance calls for a consistent set of files and database content. Having both components is necessary to assess coverage but does not prove that separately captured components belong together. If their relationship is unknown, retain both timestamps and ask the maintainer to establish the common recovery point. Do not declare consistency merely because both filenames use the same date.

Compare the capture dates with the planned change and the store activity since capture. Name what falls outside the retained copy, including later changes or orders where relevant. This page establishes coverage, not a procedure for rolling a trading store backward. Do not overwrite live transactions to find out whether an old backup works.

Use the gaps to make the release decision

If a release depends on restoring the store and either required component is absent or unknown, the backup prerequisite remains open. Assign the missing capture or coverage confirmation to its authorized owner and make the dependency visible to the release decision-maker. A verbal assurance that the host handles everything cannot close a specifically missing component.

When both components have documented coverage, record that finding precisely: coverage identified. Record genuine restoration evidence separately, including the backup it used, when the restoration occurred, who performed it and what was actually recovered. If no such evidence exists, say recoverability is unverified. Do not invent a restore exercise or claim uninterrupted operation from a complete-looking archive.

WordPress recommends backups before updates or moves and keeping backups in multiple locations. For this release, also identify who has authorized access to the retained copy and who can authorize recovery. A copy nobody responsible can retrieve does not provide a usable handoff.

For a Prism checkout-review consultation, describe the planned store change, the identified coverage gap and the recovery responsibilities that need scoping. Confirm any backup, restoration or implementation work before it begins. Share a non-sensitive coverage summary, not the archive, database, customer records or configuration secrets, through the public inquiry form.

Backup coverage record

Fill this from the retained copy, its capture record and the actual installation. Mark each component included, excluded or unknown and give a non-sensitive reference. Known coverage does not prove a successful restore; record restoration evidence separately.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.