If the data goes, is anyone keeping a copy? Probably not the platform

Ask a small business owner whether their customer data is backed up and the answer is usually a version of "it's in the cloud". Which is true, and answers a different question.

The cloud protects against their hardware failing. It does not generally protect against your mistake, and the difference only becomes interesting on the day somebody deletes the wrong thing.

Resilient and recoverable are different products

A platform having your data on redundant infrastructure means it will not disappear because a disk died. It does not mean there is a button that returns your account to how it looked yesterday morning.

Shopify's documentation is refreshingly direct about where that responsibility sits: if you want a backup of your store's information, it points you to an app from its App Store. The platform's answer to "how do I get a backup" is "install something that makes one".

The same page describes what moving a store actually involves — some information transfers using CSV files along with a copy of the theme, and other kinds have to be entered manually in the admin. Which tells you what a homemade backup covers and what it does not: your records, mostly yes; the way everything was set up, mostly no.

Some deletions really are final

The clearest example I found is Mailchimp's, in the same documentation that describes exports: deleting an audience is permanent, the vendor does not hold the deleted data, and it is therefore not something an export can bring back.

Sit with the ordinariness of that. It is not a technical failure or an extraordinary event. It is a button, in a normal interface, available to anyone with the right permissions, with a confirmation dialog that looks like every other confirmation dialog — and no undo behind it.

Most platforms have at least one of these. It is worth knowing which of yours do before somebody finds out during a tidy-up.

The three things that actually go wrong

The scenario people picture — the vendor loses everything — is the least likely of the three.

Somebody deletes something. By far the most common. A cleanup, a wrong selection, an import that overwrote rather than added. It is your own action, so no vendor guarantee applies to it.

An integration writes something wrong, at scale. A sync misconfigured on Tuesday quietly corrupting a field across ten thousand records by Thursday. The data is present, and wrong, which is harder to spot than missing and harder to undo than a deletion.

The account goes away. A card that expired while the owner was on holiday, a billing dispute, an account suspended over a policy question. The data is not lost; it is behind a door you cannot currently open, which for a business in the middle of a week amounts to the same thing.

Only the third is really about the vendor, and none of the three is solved by the platform being reliable.

The backup habit worth having

Full-fidelity backup of a SaaS account is largely not achievable for a small business, and chasing it is the wrong goal. Aim instead at being able to keep operating and to reconstruct what matters.

Export the irreplaceable on a schedule. Customers, orders, invoices, bookings — whatever your business could not recreate from memory or from paper. Monthly is fine for most. Put it in a calendar, because a backup habit that depends on remembering is not one.

Store it away from the thing it protects. A copy inside the same platform, or in the same account, shares the failure it exists to survive.

Open one occasionally. An export nobody has ever opened is a belief. Twice a year, open the file and confirm the fields you need are in it.

Photograph the configuration. Screenshots of settings, automations and field definitions cost minutes and cover the part exports do not.

Know which buttons are final. For each system, one question to support or the documentation: what here cannot be undone? The answers are short and worth having in advance.

Keep the billing alive. Several of these scenarios are really "the card expired". A second payment method on business-critical accounts is a cheap fix to a whole category.

What you would do that week

The practical test is not "do we have a backup". It is: if this system were unavailable for a week, what would we do?

For most small businesses the honest answer involves a spreadsheet and some phone calls, and that is a perfectly good answer — as long as somebody has thought about it before the week arrives, and as long as the spreadsheet can be assembled from something you actually hold.

The businesses that cope are not the ones with elaborate backups. They are the ones who could still tell you who their customers are, what was owed, and what was booked, without logging into anything.

When this needs more than a monthly export

For a business with one or two systems, the habit above covers it.

It changes when data is spread across several connected tools, because then no single export is a coherent picture: the orders are here, the customers there, the payments somewhere else, and the connections between them exist only as matching identifiers. Restoring from that is not importing a file — it is reassembling relationships, and whether that is possible depends on choices made long before the incident.

Working out what you could actually reconstruct, and what would be gone, is one of the things a process audit covers: $299, three business days, and an honest answer to the week-without question.

Sources

I read these pages in August 2026. Vendor documentation moves; check the vendor's own page. These are two vendors' policies rather than an industry standard.

Where backup responsibility sits, and what transfers versus what is re-entered by hand: Shopify on backups and duplication.

An ordinary deletion that cannot be undone or exported back: Mailchimp on exporting and backing up account data.

Related: what you actually take with you when you leave a platform covers the planned version — leaving on purpose, rather than losing something.