WooCommerce Backup and Restore Checklist
A WooCommerce backup needs both the site files and the database, plus a restore process you can use. Check coverage, access and recent orders before relying on it during an incident.
Read the guide
Search Field Notes
A useful next read.
36 field notes
No matching guide yet. Try “checkout”, “shipping” or “catalog”.
All Field NotesCheck what the backup actually contains
The database holds products, orders, customers and settings. The files hold themes, plugins, uploads and other parts of the installation. Confirm that your backup can recover the required combination, including custom code and server configuration where relevant. A copy of wp-content or a product CSV does not recover the whole shop.
List the information held elsewhere, too: payment transactions, warehouse records, email-provider configuration and any external product master. You may not need to copy all of it into the website backup, but you need to know its owner and how it relates to a recovered store. Recovery is easier when those dependencies are understood before the host or application fails.
Verify access, retention and storage
Find the latest successful backup, its timestamp, coverage and size. Check the failure history and the oldest available recovery point. A scheduled job that stopped last month is not a current backup. Make sure the business can reach the storage if the website server or the outgoing supplier is unavailable.
Keep backups protected outside the public web root. They can contain customer records, settings and credentials, so limit access and use the provider’s secure transfer process. Match frequency and retention to the amount of trading activity the business could afford to reconcile or lose. Store that decision with the recovery notes rather than copying a generic daily-backup rule from another shop.
What a restore needs to prove
Test that the backup produces a working store and account for newer orders.
Check coverage
Confirm that the backup includes the required files and database together.
Complete recovery pointRestore separately
Restrict the copy and isolate charges, email and fulfilment before testing.
Protected test environmentVerify operation
Check catalog, media, access and representative store flows.
A usable recovered shopAccount for newer orders
Identify activity after the backup and reconcile payments, orders and stock.
Before live restoration
Rehearse a restore on an isolated copy
Restore a selected backup somewhere separate from the live shop. Restrict access, prevent public indexing and isolate payment, email, subscription and fulfilment activity before testing. A recovered database can contain scheduled work and live service settings; the copy must not charge a customer or send an order to the warehouse.
Record how long the process takes and which dependencies it needs. Check that the expected catalog, media and settings are present, then run representative administration and purchase tests with safe records. A restore-tool success message only confirms that its operation finished. The rehearsal shows whether the recovered shop is useful and which parts still need intervention.
Protect orders made after the recovery point
A database restore can replace today’s records with yesterday’s state. If orders were placed in between, the payment provider and warehouse may still hold them while WooCommerce no longer does. Customer updates, refunds and stock changes also need attention. Before a live restore, identify that interval and the records affected.
Preserve the current state where possible and let the technical owner choose an incident-specific recovery or reconciliation method. A broken theme may be repairable without restoring the database at all. Do not assume that importing an order export recreates every relationship or that enabling the store immediately after restoration is safe. Check payment, fulfilment and inventory consistency before normal trading resumes.
Keep a recovery checklist someone can follow
A practical runbook identifies who makes the recovery decision, who can access the backup and how the restored copy is verified. Include the steps needed to isolate services and the contacts for external systems. The person responding to an incident should not need to find an old chat to learn which account controls the backup.
Keep the latest rehearsal date and its limits visible. Review the checklist after a hosting move, storage change or new integration. A backup plan stays useful when the business can answer these questions:
Use the answers to close specific gaps, such as inaccessible storage or missing media, before an incident turns them into urgent work.
- Which recovery point is available, and what does it cover?
- Who can restore it if the main server is unavailable?
- How will newer orders and connected-system records be protected?
- Which checks must pass before the restored shop takes orders?
Common questions
Is wp-content enough to back up WooCommerce?
No. A working recovery also needs the database and any required installation/configuration components. Confirm coverage with the host or backup provider.
Can a product CSV replace a store backup?
No. It is useful for supported product data, but it does not recover the whole application, customer/order relationships or every extension’s data.
How often should I back up a trading store?
Choose frequency according to how much new activity you could reconcile if recovery were needed. Check retention, failed jobs and restore access as well as the schedule.
Can I restore without losing newer orders?
Possibly, but it needs an incident-specific plan. Protect the current state and reconcile orders, payments and fulfilment before overwriting a live database.