This article teaches you two numbers: RPO and RTO. Once you set them, backups stop being a technical topic and become a conversation about orders. Restoring a backup is a business decision, priced in orders that will not be there afterwards.
Why a backup is harder for a store than for a regular website
A company website changes every few weeks. Yesterday's copy is practically identical to production, so restoring it costs nothing. In a store the data changes every minute, and that is the whole difference.
Imagine restoring a copy from 24 hours ago. With a working store you also roll back the database: orders from the past day, payment statuses, stock levels, new customer accounts, used discount codes, returns and complaints sent through the form. The orders disappear, the money for them stays. The customer holds a gateway confirmation, your store has no order. The payment provider sees the transaction, the warehouse sees nothing, and three days later the customer asks where the parcel is.
That is the heart of the topic. A restore is not a return to normality but a trade of one problem for another, cheaper or more expensive. Before discussing backup frequency, know what that second problem costs you.
RPO and RTO in plain language
RPO (Recovery Point Objective) answers one question: how much data can you afford to lose, or how old the newest backup may be at the failure. If the backup runs daily at three in the morning and the failure comes at six in the evening, your real RPO is fifteen hours of orders to recreate by hand.
RTO (Recovery Time Objective) answers another: how long you can be offline, from the failure to the moment the store takes orders again. This is not file copying time. It is diagnosis, decision, restore, verification and switching traffic over.
Both numbers come from one figure you already have: orders per hour. Take the last 30 days and divide by the hours in which you genuinely sell. A store doing 200 orders a day in a window from 8 to 22 has roughly 14 orders per hour. With an average basket of 45 USD, every hour rolled back is about 600 USD of revenue and 14 orders to retype. At an RPO of 24 hours that is 336 orders, which nobody retypes in one day.
Now reverse it. If your team can handle 20 orders recovered from the gateway and from email, your RPO should be about an hour, not a day. If your peak falls in November, calculate for November, not July. RPO and RTO are not constant, so the honest approach is two values: ordinary and seasonal.
What the backup must cover, because a copy of files alone is useless
The usual mistake is copying the store directory and calling it done. A complete backup has five elements:
- the database: orders, customers, products, prices, module configuration,
- application files: theme, modules and plugins, libraries, product images and attachments,
- server and service configuration: PHP version, rewrite rules, cron, queues, certificate, cache and search settings,
- keys and environment variables: database credentials, salts and encryption keys, API tokens,
- documentation of everything the store does not contain.
That last point gets skipped and can stretch a recovery by hours. It covers settings held by external services: gateway configuration and callback addresses, warehouse or ERP integration, carrier and pickup point settings, price comparison accounts, marketing pixels and tags, DNS records. None of it lives in the store database and no hosting backup includes it. A simple document listing services, panel addresses and access holders is enough.
WooCommerce adds one thing: if the store uses HPOS, the newer way of storing orders, the backup must match the plugin versions, because a partial restore can misalign the order tables. In PrestaShop the frequent problem is paid modules and their licences, which sometimes need activating by hand after a move.
The 3-2-1 rule in a store version
The rule is simple: three copies of the data, on two different media or in two locations, one of them outside the hosting provider infrastructure.
The third point causes the arguments. A backup in a directory next to the store, on the same server and account, protects against exactly one scenario: your own mistake in content or configuration. It does not protect against a disk failure, a suspended account, a deleted server, a mistake on the provider side, or losing access to the panel. If the fire takes the whole building, the copy in the next room burns with the original.
For the same reason, a backup reachable from the same account can be encrypted along with the store in a ransomware attack, so at least one copy should be immutable or outside that account, with separate authentication.
The restore test, the only difference between a backup and an assumption
The restore test is the only thing that turns an assumption into a fact:
- You restore the backup on a separate environment, never on production.
- You check whether the store starts: home page, category, product page, admin login.
- You walk the full purchase path to order confirmation, with payment in test mode.
- You compare numbers: orders, products, customers, and whether the last order matches the backup date.
- You measure the time to the moment the store would be ready for traffic. That number is your real RTO, not the one someone put in a quote.
If the test goes worse than assumed, you have two paths: shorten the RPO (more frequent backups) or the RTO (a standby environment and a written procedure). Both cost money, but you now know the price of the alternative in orders.
With us, backups run every 7 days on the basic package, and the restore test runs once a quarter, with its result and timing recorded. If your calculated RPO is below one day, the basic package is not enough, and we say so before signing.
When not to restore
During an outage the reflex is the same: restore it and be done. That is usually wrong. The order should be reversed: diagnosis first, decision second.
Run the numbers. The outage lasts three hours, the newest backup is three hours old. Restoring brings the store back without the orders from those three hours: at 14 per hour, 42 items to retype from the gateway and from email, stock levels included. If a single module caused the failure, that price is absurd.
Alternatives worth considering first:
- a fix in place: switching off the faulty module, rolling back one update, correcting the configuration,
- restoring files only, without the database: this works when the problem is in the code and the data is intact, and costs not a single order,
- maintenance mode with clear information for customers, orders by phone and email, repair running in the background.
We restore a backup when the data is genuinely damaged or when further diagnosis costs more than the hours lost. That decision belongs to the store owner, not the technical person, because the owner knows what 42 orders are worth.
A checklist for your current provider
Send these questions to whoever maintains your store, and ask for answers in writing:
- How often is the backup made and at what time?
- Where does it physically sit, and is that separate infrastructure?
- How long is it retained and how many versions back?
- Who has access, and do I have access without a middleman?
- When was it last restored, on what environment, and how long did it take?
- Does it cover the database or only the files?
- Is it a hosting backup, and if so, whose property is it and do I get it when we part ways?
- Does the contract cover returning or deleting the data after termination?
No answer to question five is the most important signal here. Question seven can be uncomfortable: a hosting backup belongs to the provider, is made on their terms, and is not always available on demand in a usable format.
What is in our service and what costs extra
Backups and the quarterly restore test are part of availability supervision, from 240 USD net per month at the Standard level. The same service covers checking the store every 60 seconds, human verification of an alert within 15 minutes, and a post incident note.
Restoring the store outside the service window is billed at intervention rates: business hours 8 to 18 is 40 USD per hour, evenings and Saturdays 60 USD, Sundays and public holidays 80 USD. We say this openly, because it surprises people most, and because the gap between a night and a daytime restore is one more argument for setting RPO and RTO in advance, calmly.
Book a review of your store backups. We will check what is actually being copied, restore a backup on a separate environment, measure how long it takes, and set the RPO and RTO for your store. Details and the form: /en/sla-help-desk.