Home / Blog / Business Applications and Automation / How to Plan Backups for an Online Store

Business Applications and Automation

How to Plan Backups for an Online Store

For a brochure site, a backup is a convenience. For an online store, it is the difference between a bad day and a business-ending one. Orders, customer records, stock levels, payment data and product content all change constantly, and every hour without a backup is an hour of orders that cannot be recovered if the server fails, the database corrupts, or ransomware encrypts the store.

This guide helps you plan backups for a store in business terms first — how much you can lose, and how fast you must recover — and then turns those answers into a schedule, a storage plan, and a test routine.

Start with two numbers: RPO and RTO

Every backup plan rests on two decisions, and they should be made by the business owner, not by the server:

  • RPO — Recovery Point Objective: how much data you can afford to lose, measured in time. If you back up the database once a day at midnight, a failure at 11 p.m. loses up to 23 hours of orders. If you back up hourly, you lose at most an hour. Your RPO is the answer to “how many orders can we afford to lose?” — and for a busy store, the honest answer is usually “very few”.
  • RTO — Recovery Time Objective: how long you can afford to be down while you restore. An hour? Four hours? A day? Your RTO decides whether a backup file on a distant server is enough, or whether you need a standby server and a rehearsed restore procedure.

Write both numbers down and get them agreed. They decide the frequency, the storage, and the budget — and they stop the backup conversation from being about gigabytes instead of about the business.

What to back up

A store has more moving parts than its files. Your backup must cover all of these:

  • The database. Orders, customers, products, stock, coupons, and settings live here. This is the most important and most frequently changing part. Back it up separately from files, and more often.
  • Files. WordPress core, themes, plugins, and the wp-content/uploads directory — product images, downloadable products, and media. A store with many product images can have a large uploads folder; do not discover its size during a restore.
  • Configuration. Web-server and PHP configuration, cron jobs, redirects, and SSL certificates. These are small, easy to forget, and painful to reconstruct.
  • Anything outside WordPress. If your store integrates with an external system — a shipping tool, an accounting package, a CRM — confirm where its data lives and whether it is backed up separately. A WordPress backup does not cover data that lives elsewhere.
  • Order and customer data exports. As a secondary safety net, keep a periodic export of orders and customers in a separate location. It will not restore the whole store, but it can reconstruct what was sold and to whom if the database backup fails.

How often: match frequency to order volume

There is no universal schedule, but the principle is simple: the busier the store, the more often the database must be backed up.

Store profile Database Full files + database
A few orders a week Daily Daily or every other day
Tens of orders a day Every 6 hours, or hourly at peak Daily
Hundreds of orders a day Hourly, or continuous replication plus hourly dumps Daily, with weekly full copies retained longer
Seasonal peaks and sales Increase frequency before the sale, and keep a pre-sale backup Before and after the sale

Files change less often than the database, so a daily full backup usually covers them — but a store that adds products daily should back up files daily too. The key rule is that a backup taken before a big change (a sale, a plugin update, a migration) is worth more than one taken after it. Take a snapshot before risky changes as well — see Server Snapshots vs Backups — but remember that a snapshot is not a backup.

Where to store backups: the 3-2-1 rule

Follow the 3-2-1 rule: three copies of your data, on two different systems, with one copy off-site. For a store, that means:

  1. The live store on the server.
  2. A backup copy on separate storage — a backup service, object storage, or a different server — in the same region for fast restores.
  3. An off-site copy in a different region or with a different provider, retained longer.

Three rules make the copies real rather than theoretical:

  • Never store the only backup on the same server. If the server fails, is wiped, or is encrypted, a backup on that server is gone with it. This is the most common backup mistake on VPS setups.
  • Isolate the backup credentials. If an attacker who compromises the store can also delete the backups — because the credentials are stored on the server — you have one copy, not two. Store backup credentials separately, and restrict who can delete backup copies.
  • Make at least one copy immutable if you can. Immutable or write-once storage cannot be altered or deleted for a set period, so ransomware cannot encrypt your backups even if it reaches them. Ask your backup provider whether immutability is available.

Retention: how long to keep copies

Keep more than the last backup. A common retention ladder for a store is:

  • Daily backups: keep for 7–14 days.
  • Weekly backups: keep for 4–8 weeks.
  • Monthly backups: keep for 3–12 months, depending on your accounting, tax and legal needs.

Longer retention matters because corruption and compromise are not always noticed immediately. Ransomware can sit quietly for days before it encrypts; a database error can corrupt data gradually. If you only keep the last two days, every copy you have may already contain the problem. A monthly copy from before the incident is the one that saves you.

Check any legal or tax requirement for how long order and customer records must be retained in your jurisdiction — that requirement may set the minimum, not your preference.

Automate, alert, and test

A backup plan that depends on someone remembering is not a plan.

  • Automate the schedule with cron or your backup tool, and make the job run whether or not anyone is watching.
  • Alert on failure. A backup that fails silently for a month creates false confidence. Alert to an inbox and a channel someone actually reads, and treat a failed backup as an incident, not a warning to check later.
  • Monitor disk space on both the server and the backup destination. Backups fail when the disk is full, and a full disk can take the live store down too.
  • Test the restore — regularly, on staging, with a timer. At least quarterly, restore the latest backup to a staging server and confirm: the site loads, products and stock are correct, orders are present, checkout works, and emails send. Record how long the restore takes — that is your real RTO, and if it is longer than the RTO you agreed, the plan needs to change.
  • Document the procedure. Write down, step by step, how to restore: where the backups live, which credentials are needed, the order of operations, and who does it. In an incident, nobody should be working from memory.

Before a sale, a migration, or an update

Take a fresh, verified backup immediately before any of these events, and keep it separately labelled. A backup taken five minutes before a major plugin update is the fastest way back if the update breaks checkout. The same applies before a migration — see How to Migrate an E-commerce Store with Less Downtime — and before a sale, when order volume makes any data loss expensive.

What a good backup plan looks like, in one paragraph

For a typical growing store: hourly or six-hourly database backups and daily full backups, stored off the server with one copy in another region, retained on a daily/weekly/monthly ladder, with failure alerts, and a restore tested on staging every quarter and timed. That plan costs a little time and storage. The alternative — discovering during an outage that the last good backup is three weeks old, on the same dead server — costs far more.

The bottom line

Plan backups from the business numbers: how many orders you can lose (RPO) and how long you can be down (RTO). Back up the database often, the files daily, and the configuration always. Store copies off the server and off-site, keep them long enough to predate silent corruption, alert on failure, and prove the restore works before you need it. A backup you have tested is a plan. A backup you have not tested is a hope.

For hosting with the storage and reliability a store’s backup plan needs, see our WooCommerce hosting plans. [TO BE CONFIRMED: whether Offshore Hosting offers managed or off-site backups for WooCommerce plans, retention, and immutability options.]

Sources

  • High-Availability.com — Snapshots vs. Backups: Securing Your Data: https://blog.high-availability.com/episode-18-snapshots-vs-backups-securing-your-data/
  • MonoVM — How to Backup a Server or VPS: The Ultimate 2026 Guide: https://monovm.com/blog/how-to-backup-a-server-or-vps/
  • ComputerWeekly — The 3-2-1 backup rule: Has cloud made it obsolete?: https://www.computerweekly.com/feature/The-3-2-1-backup-rule-Has-cloud-made-it-obsolete?ref=filebase-blog
  • LucidTrac — Safeguarding Business Continuity: Why Data Backups, Snapshots, and Rollbacks Are Mission-Critical: https://lucidtrac.com/blog/read/Safeguarding_Business_Continuity_Why_Data_Backups_Snapshots_and_Rollbacks_Are_Mission_Critical_Even_in_the_Cloud_Era

Sources

  • https://blog.high-availability.com/episode-18-snapshots-vs-backups-securing-your-data/
  • https://monovm.com/blog/how-to-backup-a-server-or-vps/
  • https://www.computerweekly.com/feature/The-3-2-1-backup-rule-Has-cloud-made-it-obsolete?ref=filebase-blog
  • https://lucidtrac.com/blog/read/Safeguarding_Business_Continuity_Why_Data_Backups_Snapshots_and_Rollbacks_Are_Mission_Critical_Even_in_the_Cloud_Era

← All guides · Knowledge Base

Related guides