# How to Plan Backups for an Online Store

- Link: https://offshorehosting.pk/how-to-plan-backups-for-an-online-store/
- Published: 2026-10-25T10:34:00+00:00
- Author: admin

# 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](https://offshorehosting.pk/blog/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](https://offshorehosting.pk/blog/how-to-migrate-an-ecommerce-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](https://offshorehosting.pk/ecommerce-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