WooCommerce
WooCommerce backups: why the usual advice is not enough
27 July 2026 · 6 min read
On this page
"Take daily off-site backups" is good advice for a website. For a shop it is incomplete, because a shop is writing data continuously and a restore deletes everything written since.
The problem with daily backups on a shop
Your backup runs at 3am. At 4pm something breaks badly enough to need a restore.
You have just deleted thirteen hours of orders. Not just the records — the customers paid, their money is in your gateway, and your shop has no idea the orders exist. You are now reconciling by hand from Stripe, chasing customers for delivery addresses, and hoping nobody ordered something now out of stock.
That is why restoring a shop is a much heavier decision than restoring a website, and why the first response to a broken shop should almost always be rolling back the single plugin rather than restoring.
What to change
Increase frequency. Daily is a floor, not a target. Hourly during busy periods, and hourly permanently if your order volume justifies it. Some backup services offer real-time database backups for exactly this.
Back up the database more often than the files. Files change when you update; the database changes with every order. Many plugins let you schedule these separately — files daily, database hourly. That is usually the right split for a shop.
Longer retention. Thirty days minimum. Malware frequently sits dormant for weeks, so a seven-day retention means every backup you hold may already be infected by the time you notice.
Off-site, always. Same as any site, and more important — a suspended hosting account takes its backups with it.
Know what a restore would cost before you need one
Write this down now, while nothing is wrong:
- How many orders do we take in an average hour? In a peak hour?
- If we restore to the last backup, how many orders disappear?
- How would we recover those orders from the gateway?
- Who decides to restore, and who does it?
The answers take ten minutes to work out and are impossible to think through calmly during an outage.
How to recover orders after a restore: your payment gateway has every transaction. Stripe and PayPal both let you export payments for a date range with customer email and amount. That is your reconciliation list. It is painful but survivable — and only if you know to do it before you email customers apologising.
Test the restore, with a shop in mind
Quarterly, restore to staging and check specifically:
- Does the restore complete at all?
- Are the most recent orders present? Not just old ones.
- Do product images appear?
- Do variations, stock levels and prices look right?
- Do tax and shipping rules still apply?
- Can you place a new order on the restored copy?
Points 2 and 6 are the shop-specific ones. A restore that brings back the site but not the last week of orders, or one where checkout no longer works, is a failed restore that looks like a successful one.
Also confirm your backup covers custom database tables. WooCommerce extensions — subscriptions, bookings, points — often create their own. Some backup plugins only include tables with your site's prefix, and some extensions do not use it.
Before big changes
A scheduled backup is not enough before anything significant. Take a manual one immediately before:
- Any WooCommerce or gateway update
- Any theme change
- Bulk product imports or price changes
- Anything touching checkout
Minutes old, not hours. That is what makes it a genuine undo rather than a decision about what to sacrifice.
A setup that works
Files daily, database hourly, both off-site, 30-day retention, failure alerts on, a manual backup before every update, and a quarterly restore test that checks recent orders.
Most of that is configuration you do once. The parts that decay are the failure alerts and the restore test, which is why they are on the maintenance checklist and included in our WooCommerce care — along with restores on request, which is the bit you actually want on the day.