Identify the restore point and the affected layer
Record the backup’s completion time and time zone, the first visible failure and the last successful order. Confirm which files and database are included and whether the backup opens on a separate protected installation. Keep the current state as a separate recovery copy, even if it is broken.
If only a known file change caused the failure, investigate a targeted file rollback with compatible software and database versions. If data is damaged, a file rollback alone is insufficient. Suspected compromise requires investigation of the entry route and the restored copy; an old backup is not automatically clean.
Build the newer-transaction reconciliation list
Compare the period after the backup across WooCommerce, the gateway and fulfilment records. Include orders, refunds, customer changes, stock movements and relevant subscription events. Record payment references securely and avoid sending card data or customer exports through ordinary chat.
A gateway record supplies payment evidence, but it does not necessarily contain product options, tax breakdown, shipping choices or consent details. Identify missing fields before promising reconstruction. Preserve identifiers and relationships with a supported recovery process rather than manually inventing replacement database rows.
Choose the narrowest workable recovery
Review the scope of your backup tool’s restore function. WooCommerce’s backup guidance explains restore points and planning around store activity. A vendor feature that preserves orders must be checked against your tool, version and extensions; it is not a property of every backup.
For a database recovery, have a specialist reconcile newer records on a protected copy first. Confirm the authoritative HPOS or legacy storage and related extension data. A spreadsheet export alone is not a complete restorable store. If no usable copy or record contains the required information, document the loss instead of claiming recovery.
Rehearse database recovery when files are not enough
Use test transactions on a disposable test installation to rehearse the selected restore and reconciliation workflow. Record versions, storage mode, backup time, missing-data assumptions and every transferred record. Keep emails contained and gateways in test mode. Copied live subscriptions must retain their staging protections.
Verify amounts and statuses against the test gateway, compare line items and customer relationships, and confirm stock is adjusted once. Include refunds and subscriptions when the store uses them. Rehearsal proves only the tested scenario; a live incident still requires its own record-by-record assessment.
Reopen only after the recovered records agree
Coordinate any pause in checkout and background writes with the host and integration owners. Preserve the latest available state before the live recovery, then check orders, refunds, fulfilment and the next scheduled subscription event. Avoid charging a customer again merely to recreate a missing order.
Test the repaired storefront and authorised payment route, then monitor new orders and callbacks. Keep an incident record of what was recovered and what remains uncertain. The general WordPress restore guide covers the broader process; subscription recovery needs separate billing checks.
Get help with the next step
If the evidence is unclear, request a backup recovery assessment. Share the symptom and checks already completed so the next step can be agreed.