iFastHostingHow to back up a store without losing orders
Restoring a store to yesterday sounds fine until you remember every order placed since then just disappeared.
A backup taken once a day sounds like reasonable practice, and it is — right up until you need to restore it and discover every order placed since that backup ran has vanished along with whatever went wrong. Store backups need to be thought about differently from a brochure site's, because the thing most likely to hurt if it is missing is not a page of content but a customer's paid order.
Why store backups are a different problem
On a brochure site, restoring to yesterday's backup loses at most a day of edits — inconvenient, rarely serious. On a store, restoring to yesterday's backup loses every order, every account created, and every stock change from that day onward. If a problem is discovered at 4pm and the last backup ran at 2am, that is fourteen hours of orders that a naive restore would erase.
Restoring an entire site backup — files and database together — rolls the whole store back to that point in time, including the orders table. If orders have been placed since the backup was taken, a full restore removes them from the system entirely unless you specifically recover them first.
Back up the database more often than the files
Product images, theme files and plugin code change relatively rarely — a daily backup of files is usually more than enough. Orders, customer accounts and stock levels change constantly, all inside the database. If your hosting or backup tool allows separate schedules for files and database, run database backups considerably more frequently than file backups, particularly during busy periods.
| What | How often, as a starting point |
|---|---|
| Files (theme, plugins, uploads) | Daily is usually sufficient — these change far less often than order data. |
| Database (orders, stock, customers) | Several times a day, or as close to continuous as your backup solution allows, especially around sales or promotions. |
| Before any update or configuration change | Always, regardless of your regular schedule — see taking a backup before any risky change. |
Recovering an order that a restore would otherwise lose
If a full restore is genuinely necessary — for example, after a hack that also touched files, not just data — orders placed after the backup point do not have to be lost permanently. Before restoring:
-
Export the current orders table if the site is still reachable
Even a compromised or malfunctioning site can often still have its database exported. A CSV or SQL export of the orders placed since the backup point preserves them outside the restore.
-
Note down payment references for anything exported
Cross-check exported orders against your payment provider's dashboard, since that is an independent record of what was actually paid that a corrupted database export cannot lose.
-
Restore the site to the clean backup
Only once the recent orders are safely captured elsewhere.
-
Re-enter or re-import the recovered orders
Manually, or via a WooCommerce order importer if the volume justifies it, so nothing is lost from the customer's perspective even though the underlying restore happened.
Test the restore, not just the backup
A backup file that has never been restored is a guess, not a safety net. Periodically restore a store backup to a staging copy and confirm orders, customer accounts and stock levels all come back correctly — not just that the site loads and looks right. A restore that brings back the homepage but silently corrupts the orders table is a failure that only shows up when you specifically check for it.
Before a big sale, a plugin update, a theme change or a payment gateway switch, take a manual backup on top of your automatic schedule. If something goes wrong, you want a known-good point to return to that is not several hours or days stale.
Backups and migrations are related but different
If you are moving the whole store to new hosting rather than recovering from a problem, the same order-preservation concern applies but the process is slightly different — see how to migrate a store without losing orders for that specific case.
The general principles of website backups — where to store them, how long to keep them, and the wider case for testing restores — are covered in how to back up your website; everything on this page adds the store-specific layer on top of that foundation.
Related reading
A store is a bigger target than a brochure site because there is more to steal and more ways in — here is where to focus first.
How to migrate a store without losing ordersA store never stops taking orders just because you are moving it, so the migration has to account for orders placed mid-move.
How to back up your websiteFiles and database, taken together, kept somewhere other than the account they protect — here are three ways to manage both.
How to restore a database from a backupThe database half of a restore has its own tools and its own common errors — here is how to do it properly.