Development

How to Back Up WooCommerce: Database, Products & Settings (2026 Guide)

WooCommerce settings stored across multiple database tables with export to CSV or JSON file for migration and backup

Every WooCommerce store is one bad plugin update, one hosting incident, or one mistaken bulk edit away from needing a backup that actually restores. This guide is for store owners and developers who want a backup setup they’ve tested — not just installed. You’ll leave knowing exactly what to back up, which method fits your store, and how to back up just the database, just products, or just settings when you don’t need everything.

Back up the layer every backup plugin misses. SnapSettings exports your WooCommerce configuration — shipping zones, tax rates, core options — to one file and restores it without touching orders or products.

View SnapSettings →

What a complete WooCommerce backup actually includes

A complete WooCommerce backup is two things: your files (themes, plugins, and everything in wp-content/uploads, including product images) and your database. Most “my backup didn’t work” stories come from capturing only one of them.

The database side is bigger than people expect. WooCommerce doesn’t keep your store in one table — it’s spread across WordPress core tables and at least seven WooCommerce-specific ones:

Data Where it lives
Products, coupons, legacy orders wp_posts + wp_postmeta
Orders (HPOS, default since WooCommerce 8) wp_wc_orders, wp_wc_orders_meta, wp_wc_order_addresses
Customers and sessions wp_users, wp_wc_customer_lookup, wp_woocommerce_sessions
Tax rates wp_woocommerce_tax_rates, wp_woocommerce_tax_rate_locations
Shipping zones and methods wp_woocommerce_shipping_zones + related tables
Store settings (currency, gateways, emails) wp_options
Analytics lookup tables wp_wc_order_stats and other wp_wc_* tables

Two practical consequences. First, back up all tables — a products-only export won’t bring back your shipping zones. Second, an active store’s database changes with every order, so a nightly backup on a busy store can mean losing a full day of orders on restore.

How often should you back up a WooCommerce store?

Match backup frequency to order volume, because orders are the one thing you can’t recreate:

Store activity Database Files
A few orders per week Daily Weekly
Daily orders Every few hours, or real-time Weekly
High volume / flash sales Real-time (every order) Weekly
Dev/staging sites Before each change Before each change

Files change only when you update plugins, themes, or upload media — weekly is usually enough. The database is where the risk lives.

Method 1: your host’s backups (good floor, bad ceiling)

Most managed hosts take daily server-level snapshots, and they’re genuinely useful for catastrophic recovery. But treat them as a floor, not a plan:

  • They’re usually daily. On a store taking orders, that’s up to 24 hours of lost sales on restore.
  • They restore everything or nothing. You can’t pull yesterday’s shipping zones out of a server snapshot without also rolling back today’s orders.
  • They live with your host. If the account is compromised or the host has an outage, your backups are in the blast radius.

Keep them on, and add at least one backup that’s scheduled by you and stored somewhere else (the classic 3-2-1 rule: three copies, two media, one offsite).

Method 2: a backup plugin (right answer for most stores)

For most store owners, a dedicated plugin is the right balance of safety and effort. What matters for WooCommerce specifically is real-time or high-frequency database backups — a feature list that never mentions orders is a red flag.

  • UpdraftPlus — the free tier does scheduled full backups to Google Drive/S3/Dropbox well. Real-time backups need the paid tier. The restore flow is the best-tested in the ecosystem, which counts for a lot.
  • Jetpack VaultPress Backup — real-time, order-aware backups stored off-site; it’s the one WooCommerce’s own docs recommend for exactly this reason. Costs more, thinks less.
  • BlogVault / WP Time Capsule — incremental backups that don’t hammer your server on large databases; strong staging-and-restore workflows.

Whichever you pick, the configuration that matters: database backups at a frequency matching your order volume, files weekly, storage off-server, and retention of at least 30 days (you don’t always notice corruption on day one).

Method 3: manual backups with wp-cli (free, scriptable, yours)

If you’re comfortable with a terminal, wp db export plus a copy of wp-content is a complete backup, and it’s easy to cron:

#!/bin/bash
# Nightly WooCommerce backup — database + uploads, 30-day retention
STAMP=$(date +%F)
BACKUP_DIR=/backups/mystore

wp db export "$BACKUP_DIR/db-$STAMP.sql" --path=/var/www/html --add-drop-table
tar -czf "$BACKUP_DIR/files-$STAMP.tar.gz" -C /var/www/html wp-content

# Ship offsite (S3, rsync target, anywhere that isn't this server)
aws s3 cp "$BACKUP_DIR/db-$STAMP.sql" s3://mystore-backups/
find "$BACKUP_DIR" -mtime +30 -delete

Restoring is the same in reverse: wp db import db-2026-07-05.sql and untar the files. The strength of this approach is also its weakness — it does exactly what you scripted, and nothing you didn’t. If you never scripted offsite copies or never tested a restore, you have a .sql file, not a backup.

Backing up only the database

Before a plugin update or a bulk price change, you often want a fast database-only snapshot: wp db export pre-update.sql takes seconds even on large stores. phpMyAdmin’s export works too, but on databases past a few hundred MB it times out; use the command line or your plugin’s database-only option instead. Remember this snapshot is coupled to that moment — restoring it later overwrites any orders placed since, which is exactly why the next two sections exist.

Backing up only products

Products change on a different schedule than orders, and you’ll want them separately when reorganizing the catalog or seeding a new site. Two good options:

  • The built-in CSV exporter (Products → All Products → Export) covers products, variations, and images by URL reference. Simple, but re-importing regenerates IDs — links between grouped/upsell products can need re-mapping.
  • wp-cli: wp export --post_type=product produces a WXR file that preserves more relationships.

Product images live in your uploads folder, not the export file — a CSV without a files backup restores a catalog full of broken image links.

Backing up only settings — the layer everything else skips

Here’s the gap in every method above: none of them can restore just your configuration. Tax rates, shipping zones, gateway setup, and emails are entangled with the rest of the database — you can’t restore “settings as of yesterday” from a full snapshot without also rolling back orders and customers.

That matters constantly in real workflows: pushing tested tax settings from staging to production, rebuilding after someone deletes shipping zones mid-day, or keeping a settings baseline in version control. We built SnapSettings for WooCommerce for exactly this layer — it exports WooCommerce settings (shipping zones, tax rates, core options) to a single file and restores them atomically, without touching products, orders, or customers. We wrote up the details of what general backup plugins miss about WooCommerce settings if you want the full technical picture, and how the same file makes cloning a store’s configuration a ten-minute job.

Test your restore before you need it

An untested backup is a hope, not a plan. Once a quarter, prove yours works:

  1. Spin up a staging site (most hosts have one-click staging).
  2. Restore your latest backup there — files and database.
  3. Check the four things that break silently: product images load, a test order completes, tax and shipping calculate correctly at checkout, and admin emails send.
  4. Time it. That number is your real recovery time, and it’s always longer than you assumed.

The first restore drill almost always surfaces something — a missing table, an uploads folder that wasn’t included, a serialized URL that didn’t survive the domain change. Better to find it on staging on a Tuesday than on production during a sale.

Frequently asked questions

Does WooCommerce have a built-in backup feature?

No. WooCommerce inherits WordPress’s tooling, which has export files but no true backup system. You need your host’s snapshots, a plugin, or wp-cli — ideally two of the three.

How do I back up WooCommerce without a plugin?

Export the database with wp db export (or phpMyAdmin) and copy wp-content — that’s a complete backup. Automate it with cron and ship copies offsite, or it will quietly stop being done.

How often should I back up my WooCommerce database?

As often as you take orders you can’t afford to lose. Daily for low-volume stores, hourly-to-real-time once orders arrive daily. Files only change on updates — weekly is fine.

Can I back up just my WooCommerce products?

Yes — the built-in CSV exporter or wp export --post_type=product. Back up uploads too, since images aren’t in the export, and expect to re-map cross-product links on import.

Can I restore WooCommerce settings without restoring the whole database?

Not with a general backup plugin — settings are entangled across seven-plus tables. A settings-layer tool like SnapSettings exports and restores configuration independently of orders and products.

How long should I keep old backups?

At least 30 days. Data corruption and bad imports are often discovered weeks later; a rolling window of dailies plus monthly archives covers both fast and slow disasters.

Your database and files are covered — now cover your configuration. SnapSettings gives you one-click WooCommerce settings backups you can restore on any store, any time.

Get SnapSettings →


Want help applying this?

Tell us your workflow and we'll point you to the right plugin or next step.