A rollback must account for orders received since the backup
Treat every database record created or changed after the proposed recovery point as potentially at risk within the restore’s scope. That includes new orders and later changes to orders that already existed: payment updates, refunds, fulfillment notes and inventory movements. Establish the backup’s actual database capture time, inventory the intervening activity and require a preservation and reconciliation approach from an authorized owner before a destructive restore. A backup filename or a working old homepage cannot establish that current order history will survive.
For: A research-only merchant considering an older WordPress database as a recovery point while the store has continued receiving or updating orders.
Use the database recovery point as the time boundary
The relevant boundary is the point represented by the database copy being considered. Record its timestamp and time zone, the site it belongs to, and the host or backup system’s description of what was captured. A download time can be later than the data it contains. If the capture process represents a range of times rather than a clearly identified point, record that uncertainty instead of selecting a convenient cutoff.
WordPress’s backup guide distinguishes the database from site files. A typical complete recovery needs both, in a consistent set; copying the WordPress directory ordinarily does not copy the database. Themes, plugins, uploads and configuration can also matter to recovery. Establish the exact restore scope before deciding which current records it could replace.
A promise that the host takes backups does not identify this account’s retrievable copy, its age or whether it can be restored. The person proposing recovery needs to identify the actual available set and the evidence for using it.
Include updates to older orders, not just new sales
List orders created after the capture boundary using genuine store records. Then examine orders created earlier but changed afterward. An older order can have a newer payment update, refund entry, shipment reference, customer-service note or cancellation. Filtering only by order creation date leaves those changes outside the inventory.
For each affected record, identify what changed, when it changed, where its authoritative evidence remains, and what the older copy would show instead. Keep payment-provider and fulfillment references alongside the store references in restricted internal records. A database restore should not be treated as reversing a payment already processed or a shipment already dispatched; those external events need reconciliation with the recovered store.
Include operational data beyond the order list where the proposed restore touches it. Record stock adjustments, catalog edits, relevant configuration changes and any integration records needed to explain the orders. This is an inventory of the actual installation, not a claim that every extension stores its data in the same tables or exports it through the same tool.
Separate a preserved copy from a usable reconciliation method
For each kind of activity, ask the preservation owner to identify the copy that will remain available, its coverage and who can retrieve it after recovery. A file named orders is not sufficient evidence of coverage for refunds, private notes or extension-specific fields. Record known omissions and preserve source references so the team can resolve them.
The owner must also explain how the preserved activity will be reconciled with the recovered system. Do not assume an export can be imported, that old and new identifiers will match, or that replaying an integration instruction is safe. A method that retains evidence for reading may still be insufficient for restoring operational state.
A WooCommerce system status report can help document the current versions, site addresses and active plugins against the intended recovery configuration. It is a configuration snapshot, not a copy of the intervening orders and not evidence that those orders can be reconstructed. Keep the report separate from the activity inventory.
Make the authorization cover the remaining interval
The inventory has an end time as well as a start time. If orders or updates continue while the decision is being made, the preservation boundary keeps moving. Before authorizing recovery, name who accounts for activity after the first inventory was taken and which operating restrictions, if any, the merchant has authorized during recovery. Do not silently treat a stale export as complete.
The written decision should identify the recovery set, scope of replacement, activity preserved, unresolved gaps, restoration owner and person authorized to proceed. Where a required category has no preservation or reconciliation method, keep the destructive restore on hold. A narrower correction may be worth evaluating, but its feasibility has to be established for the actual defect.
After authorized recovery, the acceptance question is whether the identified orders and later changes reconcile with the retained evidence, including external payment and fulfillment records. A site that opens is only one part of that answer. For a Prism checkout-review consultation, bring the affected checkout behavior and a summary of the recovery boundary; confirm any preservation, recovery and implementation responsibilities before work.
Post-backup activity boundary
Complete this before deciding on a database replacement. Use internal record references and real capture times. An unknown row is an unresolved recovery dependency, not zero activity. Keep the inventory current through the agreed recovery boundary and retain the underlying records in authorized storage.
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.
Post-backup activity boundary. The last column is for temporary notes.
Boundary item
Evidence to retrieve
Required interpretation
Your record
Backup timestamp and scope
Evidence to retrieveActual database capture time, time zone, site identity and associated file-set reference.
Required interpretationIdentify which data would be replaced; distinguish capture time from download time.
Orders since capture
Evidence to retrieveReal orders created between the recovery point and the inventory end time.
Required interpretationName the records absent from the older copy and where their current state is preserved.
Older orders changed later
Evidence to retrieveOrder history for pre-existing orders with post-capture payment, cancellation or support updates.
Required interpretationCreation-date filtering alone does not cover these later changes.
Refund and fulfillment changes
Evidence to retrieveStore entries matched to provider or fulfillment-system records for the same order.
Required interpretationAn older database is not evidence that external money movements or shipments were undone.
Inventory and configuration changes
Evidence to retrieveRecorded stock adjustments, relevant catalog changes and current installation details.
Required interpretationIdentify dependencies the order list alone would miss; do not assume an export contains them.
Preservation owner and method
Evidence to retrieveNamed owner, retrievable copy location, coverage limits and proposed reconciliation method.
Required interpretationSeparate keeping readable evidence from safely restoring operational state.
Activity after the inventory
Evidence to retrieveInventory end time and authorized handling of subsequent orders and updates.
Required interpretationClose the moving time boundary before treating preservation as complete.
Authorized recovery decision
Evidence to retrieveNamed approver and executor, chosen set, replacement scope and unresolved exclusions.
Required interpretationProceed only within the recorded authorization and with the required preservation approach established.
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.
Limits
This is a pre-restore decision worksheet, not an instruction to overwrite a live database or merge order tables.
WordPress backup guidance and WooCommerce status reporting do not establish retention, export coverage or recoverability for a particular host or extension.
Keep order exports and customer records in authorized storage. Do not put card details, private payment links, API secrets, bank details or identity documents in the worksheet or consultation form.
WordPress backups — checked 2026-09-29. A typical complete restore needs database and files in a consistent set; a directory copy ordinarily excludes the database. The general guidance does not establish a particular host account’s retention or recoverability.
WooCommerce system status report — checked 2026-09-21. The report records WooCommerce and WordPress versions, site addresses and active plugins. These configuration details help identify the installation but do not preserve the post-backup order history.