A company website restored from yesterday’s copy looks like yesterday and nobody notices - a store put through the same procedure has a hole where paid orders used to be. That is the whole difference between backing up a website and backing up a store, and it is why WooCommerce backups need a different approach than a copy of a blog or a brochure site. The question is not whether you make a copy. It is what is in it, which minute it comes from, and whether anyone has ever tried to restore it.
The basics - how a file copy differs from a database copy, why the host’s backup is not enough, what the three-copies rule means - are in my post on WordPress backups that actually restore, and I will not repeat them here. This post starts where that one ends: in a store where the database has a life of its own and every hour without a copy is real money.
WooCommerce backups - database, orders, a copy kept off the server
On an ordinary company website the value sits in files: the theme, the photos, the texts nobody has touched for months. The database rarely changes, so a copy from last week is practically as good as a copy from an hour ago.
A store is the other way round. The files are large but boring - product photos and plugins change every few days. All the action is in the database: a new order, a status switched to paid, stock taken off the shelf, a coupon used, a new customer account, a note from support. A store database changes every minute, and during a promotion every few seconds. A WooCommerce database backup is not an archive - it is a snapshot with an hour and a minute on it.
The most important consequence follows from that: the gap between the last copy and the failure is exactly the number of orders the store will not have after a restore. If the copy runs once a day at three in the morning and the server dies at five in the afternoon, the restored store remembers nothing from that day. Customers have paid, the payment gateway has the money, the courier may already be on the way - and the orders panel shows none of it. Stock that was sold goes back on the shelf and the store sells goods it no longer physically has.
That gap is a business decision, not a technical one. For a store with a handful of orders a week, a day is fine, because the missing orders can be rebuilt by hand from emails. For a store that sells around the clock, the acceptable gap is measured in hours or minutes.
The second store-specific issue is the consistency of the copy itself. An order in WooCommerce does not live in one place: the order itself, its line items, the addresses and the metadata are stored separately, and with the newer order storage I described in the post on moving to HPOS, the store has its own set of tables for all of it. If the copy is made while the store is busy and the tables are dumped one after another, the order may already be there while its line items are not yet. So I always ask whether the database copy is taken as one consistent snapshot of a single moment. Database dump tools can do that, but it has to be switched on deliberately.
What helps: check the time stamp on the most recent database copy you have, then count in the orders panel how many orders have come in since. That number is your real loss if the store went down right now. If it makes you wince, the copies run too rarely.
How often and where
Since files and the database live at different speeds, there is no reason to copy them to the same rhythm. I split them into two streams.
Database - often, matched to the pace of sales. In stores that sell daily I set the database copy to run every few hours, and more often in season and during promotions. A store database is usually small next to the photo folder, so frequent copies do not eat space or server resources. For bigger stores I go a step further: a database with continuous change logging, which lets you return to any minute, not just to the hour of the copy. More and more hosts include it in the price.
Files - less often, because they change less often. A full copy once a night is enough for most stores, plus one before every change to code, theme or plugins - the same habit I laid out in the safe WooCommerce updates checklist. Product photos can be copied incrementally, meaning only what has been added since last time.
Now where to keep a WooCommerce backup. Off the server the store runs on, and ideally with a different provider than the host. The most dangerous failures - a break-in, a server encrypted by ransomware, a hosting error, an unpaid server invoice - take the site and the copy down together if they sit in the same place. The host’s backup is a good extra, not the only location.
Three questions I ask when choosing where the copies live:
- How long are copies kept? A fault in a store is not always visible straight away. A quiet plugin corrupting stock levels, or a break-in that only listens for weeks, surfaces late. You need copies from different moments: the last few days densely, the last few weeks more sparsely, a few copies from recent months.
- Who has access to them? A database copy holds customers’ personal data: names, addresses, phone numbers, purchase history. A copy on an open cloud drive or sent by email is a leak waiting for an occasion. I encrypt copies and limit access to the people who actually restore the store. A caveat: I write this as a store practitioner, not a lawyer - confirm your obligations around personal data and the contract with your backup provider with someone who handles data protection professionally.
- Can the database be restored on its own? In a store failure you most often need to roll back only the database and leave the files alone, or the reverse. A solution that can only restore everything at once forces you to roll back photos and plugins just to get the orders back.
What helps: write down a simple schedule - database how often, files how often, where they live, for how long, who has the password. If the answer to any of these is “I don’t know”, that is the first thing to settle before anything happens.
A restore test - without it the backup does not exist
I repeat that sentence for every website, but for a store it has an extra floor. On a brochure site the restore test is “does the page open”. In a store, a restored copy can do damage before you even check whether it works.
You restore yesterday’s copy under a test address. The copy comes up, and with it every automation: scheduled tasks that see orders without a sent email and send it to customers again, a courier plugin that registers parcels a second time, an invoicing integration that issues duplicates, a payment gateway being polled for statuses. The customer gets a second “your order is ready” email, the accountant gets duplicate invoices, and you find out after the fact.
That is why a store restore test starts with cutting things off, not with checking. Before the copy runs its first background job, I do three things:
- Cut outgoing email. The test copy must not send a single email to a customer. I disable sending entirely or redirect everything to one test mailbox.
- Disconnect the integrations. Keys for the payment gateway, the courier, invoicing, the wholesaler get set to empty or to the provider’s test mode. An integration left with production keys behaves like production.
- Stop background jobs and hide the copy from search engines. The test address goes behind a password so Google does not index a second store with the same products.
Only now does the actual test begin. I do not ask “does the page open” - I check the things that say whether the copy is complete and current:
- The last order number matches the time of the copy. A copy from three in the morning should have its last order from the previous evening, not from last week.
- The number of orders from the last few days is the same as in the production store for the same period. A mismatch means an incomplete database copy.
- Stock levels of a few random products match what they were at the time of the copy.
- A customer account - I log into a random account and check the history and addresses.
- Product images load, not just titles. This catches a file copy that broke off halfway.
- The full purchase path on the gateway in test mode: cart, details, payment, confirmation email to the test mailbox.
And the thing people forget: I time it. From “starting the restore” to “you can buy”. That is your real recovery time after a failure, and the only way to know it is to measure it calmly. If the restore takes half a day because the file copy is enormous, better to know that today.
I write the whole procedure down in one document: where the copies are, what to cut off, in what order to restore, what to check. On the day of a failure nobody has the headspace to invent it.
What helps: put the restore test in the calendar like a car inspection - after every major change to the store and at least once a quarter. A copy last tested half a year ago, with changed plugins and a new order storage, is just hope again.
What about orders that came in after the copy
Even with dense copies, a gap remains after a failure: orders placed between the last copy and the moment the store went down. They are not in the restored database, but they really happened and the customers are waiting.
The store is not the only place that knows about them. The payment gateway has a list of transactions with amounts, times and customer emails. The courier panel has the registered parcels. The invoicing software has the documents. The store mailbox has copies of the confirmations. These are your second sources of truth, and the first thing I do after a restore is reconcile them with the orders panel: transaction by transaction from the time of the copy to the time of the failure, rebuilding the missing orders by hand with the same items, amount and address. For a few orders that is a quarter of an hour. For a few hundred it is a day’s work, and that is exactly why the database copy frequency is chosen to match the pace of sales, not the plugin’s default setting.
Stock correction comes in the same package. After the restore, stock levels rolled back with the database, so goods sold after the time of the copy show as “in stock” again. If you do not fix that straight away, the store sells them a second time.
When to take it off your plate
It can all be done yourself, and for a small store that sells occasionally that is exactly what I advise: database copy daily, files weekly, a location off the server, a restore test once a quarter with the checklist above. That is what a sensible online store backup looks like when a day of downtime does not hurt.
The line runs where the store earns enough that a day without orders hurts, and you have no time to remember backups between serving customers and handling stock. Under ongoing support, database and file copies run at a rhythm matched to the store, live off the server, and I am the one who runs the restore test and gets the alarm when a copy fails. In a failure I restore the store by a tested procedure, and you get a message that it is working, plus a list of orders to fill in if any gap remains. Backups are one of five elements of care; the other four are in my guide to WooCommerce store care.
Frequently asked questions
How often should a WooCommerce store be backed up? The database as often as orders come in that you would not want to rebuild by hand - every few hours in stores that sell daily, continuous change logging under heavy traffic. Files once a day, plus always before a change to code or plugins.
Is the backup my host makes enough? As an extra, yes; as the only safeguard, no. It sits in the same place as the store, rarely matches the pace of sales, and often restores everything rather than just the database. You need at least one copy off the server, with a different provider.
What happens if I restore a store copy without disconnecting the integrations? The restored copy behaves like a live store: it can send customers repeated emails, register parcels a second time or issue duplicate invoices. Before the test you cut off email, swap integration keys for test ones and stop background jobs.
How do I check that a store backup is complete? Restore it under a test address and compare it with production: the last order number, the number of orders from the last few days, stock levels of a few products, a customer login and image loading. A mismatch on any point means the copy does not contain everything.
Would rather not watch over it every month yourself? I take sites and stores under ongoing care - backups, updates, monitoring, and priority when something breaks. Tell me what you run and I will send back scope and price.