This lesson assumes you already know how to take a backup that actually restores — the mechanics are the same. What changes on a store is that the database won’t hold still. Orders arrive at 2 a.m., and every one that lands after your snapshot exists only in the live database until the next one runs. On a brochure site, restoring yesterday’s backup loses a typo fix. On a store, it loses money and a customer who’s expecting a package.

Understand why stores break the normal backup rules

A backup is a photograph of a moving river. The gap between the photo and right now is your exposure: restore the backup, and every order in that gap vanishes from your database — though not, mercifully, from your payment gateway, which charged those cards and remembers doing it. Two rules fall out of this. Back up more often than a quiet site would (daily is the floor; hourly during a sale isn’t paranoid), and treat any restore as an event with a known gap, not a clean rewind. More on the ongoing-care side of this in Keeping an online store alive.

Time backups for the quiet hours

Find your store’s slack water. Your orders report (WooCommerce → Analytics, or your platform’s equivalent) shows sales by hour — most US stores bottom out somewhere between 2 and 5 a.m. local. Schedule the daily dump there:

# WooCommerce
wp db export backups/store-$(date +%Y-%m-%d-%H%M).sql

# Drupal Commerce
drush sql:dump --gzip --result-file=../backups/store-$(date +%Y-%m-%d-%H%M).sql

The timestamp in the filename matters more here than anywhere else — it’s the left edge of your order gap, and you’ll want to read it under stress. Put this on a schedule and ship a copy off the server, per automate-offsite-backups.

Never push a stale database over live

The staging-push rule, and it’s absolute: code goes up, databases come down. A staging database is a copy of live from whenever you made it — push it to production and you erase every order since, instantly and silently, with no error message. It’s the single most expensive mistake in store maintenance and it always happens with good intentions, usually while deploying something unrelated. If your host has a one-click “push staging to live” button that includes the database, learn which checkbox excludes it before you ever need the button in a hurry.

Rehearse the restore with the order gap in mind

Restore last night’s backup to staging or a local copy and confirm the site comes up — that part is the standard drill. Then do the store-specific half: find the newest order in the restored copy and note its timestamp. Everything on live after that moment is your gap. Write down, while calm, what a real restore would require: pause the store (a maintenance page beats selling into a database you’re about to replace), restore, then re-enter the gap orders by hand from the gateway’s records before reopening.

Verify against the gateway’s records

The gateway is your independent witness. Open the Stripe, PayPal, or Authorize.net dashboard and compare the last few charges against the newest orders in your backup — the difference is the gap, and every charge in it has the customer, amount, and items you’d need to reconstruct the order. If the newest backup order and the newest charge sit within one backup-cycle of each other, your schedule is honest and your restore plan is real. That cross-check is the verification: a store backup isn’t proven by restoring the database, it’s proven by knowing exactly which orders it doesn’t hold.