Why backups belong in a fraud and risk discussion
Fraud, hacking, human error and plain bad luck can all end up in the same place: the store is broken, data is wrong or something is missing. A mistaken bulk edit can overwrite thousands of product records. An attacker who gets into the admin area can delete content or lock the owner out. A failed update can break the site. A backup you can actually restore turns these from disasters into inconveniences.
The word “recovery” matters as much as “backup”. Having copies is the first half. Knowing how to put them back, how long that takes and who does it is the second.
What to back up
Think about everything that would be painful to recreate. For most stores that includes:
- Store data. Products, variants, prices, categories, customer records, order history, discount codes and stock levels. This is usually the most valuable part.
- Content. Pages, blog posts, policies, images and videos. Product photos taken at home are easy to forget and hard to replace.
- Theme and design files. Templates, custom code, style settings and any changes made to the look of the store.
- Settings and configuration. Shipping rates, tax settings, payment and email settings, redirects and connected apps. These are often kept only on the platform and are a pain to rebuild from memory.
- Business records. Invoices, supplier lists, bookkeeping exports and contracts, which may be kept elsewhere but still need copies.
- Domain and account details. Registrar logins, DNS records and recovery contacts. Losing access to these can take a store offline even when the data is safe.
Write a short inventory listing where each item lives. The exercise often reveals data that no one thought of as being at risk.
What a hosted platform does and does not cover
On a hosted store builder, the provider usually looks after the servers and the underlying data, but that is not the same as giving the owner an easy undo button. Some platforms keep their own backups for their own recovery and may not restore an individual store on request. Often the owner is expected to export products, customers and orders regularly. What is offered varies, so read the provider’s documentation and test the export rather than assuming.
On self-hosted stores, backups are more clearly the owner’s job, or the hosting company’s if it offers them as a service. Both the files and the database need to be covered, and a host’s backup is best treated as a bonus rather than the whole plan. The choice between the two setups is discussed in the article on self-hosted stores.
How often
The right frequency depends on how much you can afford to lose. A simple way to think about it is to ask: if the store were restored to its last backup, how many orders and edits would be gone, and could they be rebuilt?
- A store taking dozens of orders a day usually wants the database backed up daily or more often, since lost orders are hard to reconstruct.
- A store that changes slowly may be fine with weekly copies of content and a daily copy of orders.
- Before any large change, such as a theme update, bulk product import or a platform migration, make an extra copy first.
Automation helps, because manual routines tend to be forgotten. Even so, check from time to time that the automatic job is still running.
Where to keep copies
A common rule of thumb is to keep more than one copy, on more than one kind of storage, with at least one stored away from the main system. The reason is simple: a backup stored on the same server as the store can be lost in the same incident. If an attacker deletes everything they can reach, they may delete backups stored in the same account too.
Practical points:
- Keep at least one copy that is separate from the store’s own login, so a compromised admin account cannot touch it.
- Protect backups with strong access controls, since they contain customer data. Encrypting them is often sensible.
- Keep a few older versions rather than only the latest one. A problem may not be noticed for days, and the newest copy may already contain it.
- Do not leave customer exports lying around on laptops or shared drives. Good habits here fit with the broader security best practices for a store.
Rehearse the restore
Many owners discover that their backups are incomplete or unusable only when they need them. A rehearsal catches this early. Once or twice a year, and after any major change in setup, try the following:
- Pick a recent backup and restore it to a separate test environment, not the live store.
- Check that products, images, customer records and recent orders appear and look correct.
- Open the key pages, add something to the cart and place test orders to confirm the basics function.
- Time how long the whole process took and note anything confusing or missing.
- Fix the gaps in the backup routine and update the written steps.
The timing is useful. If a restore takes a full day and the store makes most of its sales on weekends, that is worth knowing in advance.
A short recovery plan
Keep a one-page document, stored somewhere outside the store, listing:
- Who is responsible for decisions and who can perform a restore.
- Where the backups are, and how to log in to reach them.
- Contact details for the host, platform support and payment provider.
- The order of steps: secure the accounts first by changing passwords and reviewing admin users, then restore, then check, then reopen.
- How to tell customers if there is a delay, and how to handle orders placed during the gap.
Securing access before restoring is important. If the cause was a compromised login, restoring to the same insecure state invites a repeat. After an incident, review who has admin access, turn on stronger logins where possible, and look for what let the problem in.
Nothing here guarantees that a store will never lose data, but a tested plan reduces both the damage and the stress when things go wrong.