Hey, just the other day I posted an <a target="" href="https://www.sfcclearning.com/blog/sfcc-backups-real-world-guide/">article where I talked about a real implementation related to backup systems</a> in Salesforce Commerce Cloud. In that post, we explained the typical setup you do in staging to back up certain stuff, why you do it, how often, how many copies you keep before overwriting them with the next run, all that.We also said it’s great to have backups, but be careful. Those backups stay inside the instance. So, if something bad happens to your machine, your pod or whatever, well... the backups are gone with it. So yeah, you also need to set up something that takes those backups out of the instance automatically and saves them somewhere else.Anyway, I won’t go into more detail here, cuz you’ve already got the article for that, and I’ll share the link so you can check it out.Now, why am I telling you this?Well, recently we had a problem in production. Our product catalog ended up with a wrong field. The product brands were filled with the wrong values. They didn’t match what we wanted to show on the ecommerce. Not now, I mean... now it's fixed. But it was a mess.So what happened?We’ve got a middleware that takes the original SAP files, processes them, and creates XMLs to import into Salesforce. There was a development we still had to test. It should’ve only been deployed to UAT or Development, where we do our tests.But guess what? A dumb mistake and... boom. It got deployed to production.And we also have nightly processes that update the catalog automatically and replicate it to production. So yeah, suddenly we had hundreds of thousands of products with wrong info showing up.How did we fix it?First, we found the root cause. We saw that it was in the middleware. Some changes got deployed even though they weren’t approved. So first thing was to roll those changes back in prod, so it wouldn’t mess things up again the next day.Second, we restored the data backup we had set up in the staging instance. Then we replicated that to production. Luckily, we had three copies of the same backup. And lucky us, because the latest backup also had the error in it, since the issue started a couple of days ago and we only noticed today.<img src="https://ezycourse.b-cdn.net/4154/cmdpknv5301ercj8zdv0j702e.webp" alt="image" draggable="true" style="width: 629px; height: auto; cursor: pointer; margin: 0px auto;">So yeah, it really matters how many copies you keep. We had to use the one from two days ago. If we had kept just one, we’d be screwed.Another option we considered was, after fixing the middleware, to rerun the jobs that load the catalog into staging and replicate that. But here's the thing: the middleware generates files that are imported using merge mode in Salesforce. So the bad info wouldn’t really disappear. It’d still be there.So yeah, backups saved the day. We restored one and fixed the issue in production.<hr>Like this kind of real-world SFCC content? Don’t miss the next one. Subscribe for free and get it straight to your inbox: 👉 <a target="_new" rel="noopener" class="" href="https://www.sfcclearning.com/subscribe">www.sfcclearning.com/subscribe</a> 👈

A real-world mistake in production showed us the importance of having multiple backups in Salesforce Commerce Cloud. Learn how keeping more than one saved our store from a major data issue.

Why You Should Keep More Than One Backup

Discover expert insights, best practices, and in-depth guides on Salesforce Commerce Cloud. Stay ahead with SFCC Success Secrets and optimize your e-commerce strategy today!

Why You Should Keep More Than One Backup

Why You Should Keep More Than One Backup

Related Posts

When “Created” Orders Become a Headache in E-commerce

Shopify, AI, and Internal Hires: The Brutal Truth About Salesforce B2C Careers in 2025

Humans 1 – Machines 0: The E-commerce Glitch You Won’t Believe

What the heck is going on with my Salesforce instance?

How I Wasted My Morning Like a Total Idiot