On my first week at a new client, I asked a question about their ecommerce backup strategy. The platform ran on Commercetools, processed millions in transactions every day, and the answer I got was silence. Nobody in the room could tell me what would happen if we lost the product catalog tomorrow.
That silence is the whole story. Let me tell you how it ended.
SaaS does not mean safe
Everyone assumed Commercetools had backups covered. It is a managed SaaS platform, so surely the vendor handles it, right?
Here is the uncomfortable truth: Commercetools has no built-in backup scheduler and no point-in-time recovery. Your products, categories, prices, and customer records all live there, all of them mutable, all of them fragile. The vendor keeps the service running. Your data is your problem.
Think about what that means in practice. One bad import script — a mismapped column, a wrong environment variable, a junior engineer running a migration against prod instead of staging — can overwrite thousands of product records in seconds. There is no undo button. Without a backup you are rebuilding by hand for weeks, and that is assuming you even remember what the clean state looked like. For a catalog with custom attributes, tiered prices, and category trees, "remembering" is not realistic.
The team was sleeping fine before I asked. That is the dangerous part. The absence of a backup does not hurt until the day it does, and by then it is too late to build one.
What I actually built
The solution did not need to be exotic. It needed to be reliable and it needed to run without anyone thinking about it.
I built an automated export system on Azure Logic Apps. Every day, on a schedule, it pulls all the critical data types out of Commercetools — products, categories, prices, customers — and writes them to Azure Blob Storage with a proper retention policy. Daily snapshots, versioned, aged out on a rule so storage does not grow forever.
That is the part most teams stop at. A scheduled export, a folder full of JSON, a green checkmark in a dashboard. It feels like a backup. It looks like a backup on the architecture diagram. And it will absolutely fail you when you need it.
The difference between a real backup and a checkbox
A backup you have never restored is not a backup. It is hope with extra steps.
So the export was only half the work. The other half was proving the export was worth anything:
- Record count checks after every single export, so a run that silently pulls half the catalog gets caught the same day, not six months later during an incident.
- Schema integrity verification, because a file that exists but does not parse is worse than no file — it gives you false confidence.
- Automated restore dry-runs every week, where the system actually reads a backup back and confirms it can be reconstructed into valid Commercetools objects.
- Slack alerts the moment anything fails validation. Not a weekly report nobody opens. An immediate ping, loud enough to interrupt.
That validation layer is the entire difference between a backup that saves your quarter and a folder of files that quietly rotted three weeks ago.
The disaster recovery test that changed everyone's mind
Numbers on a slide do not move people. A demonstration does.
So we ran a real disaster recovery simulation. We took a copy of the environment and corrupted the product catalog on purpose — thousands of products with their prices, categories, and custom attributes wiped, exactly the way a bad import would do it.
Then I asked the team to estimate the recovery. Without the backup system, the honest answer was weeks of manual reconstruction, and they were not even confident they could get back to the original state at all.
We hit restore. Full recovery in under one hour.
The room went silent again — but a different kind of silence this time. The budget for the backup system, which had been an open question, was approved permanently before the meeting ended. Nobody argues the value of insurance after they watch the building not burn down.
Build it before you need it
If you run an ecommerce platform on any SaaS backend — Commercetools or anything else — assume nothing about backups until you have read the fine print and tested a restore yourself.
- SaaS keeps the service alive. It does not protect your data from you.
- An export you have never restored is a decoration, not a backup.
- Validation and a rehearsed recovery are the actual product. The files are just the raw material.
The best time to build a backup strategy is before you need it. The second best time is today. The worst time, by a wide margin, is in the middle of the incident.
So here is the question I will leave you with, the same one that started all of this: when did you last actually run a restore from your backups — not talk about it, not point at the pipeline, but really run one and watch the data come back?