Why a restore needs a plan first, and an undo after

The dangerous part of a backup app is not the backup

Reading your store and storing copies cannot break anything. The dangerous moment is the restore: it writes into a live store, over data that customers are looking at right now. A restore button that simply applies an old snapshot is a bulk edit with better branding - and it deserves the same caution you would give any tool that is about to touch every record at once.

Two mechanisms turn that write from a leap of faith into a routine operation: a plan you approve before anything happens, and an undo that works after it did.

What a plan is for

A plan is the exact list of what would change, computed by comparing the snapshot against the live store - not a confirmation dialog that says "are you sure?". The difference shows up in three places.

It counts what already matches. Most of a store usually matches the backup. A plan that says "2,000 records would change" when you expected one tells you that you picked the wrong date before anything is written, not after.

It names what is missing. A record that was deleted since the snapshot cannot be put back in place: Shopify does not revive deleted records, so it comes back as a new record with a new ID. That is a different promise than "restored", and you should read it before agreeing to it, because links from outside your store to the old ID will stay broken.

It freezes what you approved. Applying writes exactly the plan you saw. If a record changes between the plan and your click - a sale, a colleague, another app - writing the snapshot over it would silently destroy an edit nobody approved. The honest behaviour is to skip that record and say so, and it is the plan that makes the check possible: it recorded what the record looked like when you said yes.

A restore carries more than the field you meant

Here is the example that convinced us to be strict about this, from our own testing this week. A merchant fixes a typo by rolling one product back to yesterday's version. The product looks right. But a product version is the whole record: the rollback also carried the shipping weight of a variant as it was yesterday. If the weight changed since - a supplier update, a repackaging - the store now charges wrong shipping on every order of that product, and nothing on the screen looks broken.

A plan cannot read your mind, but it shows the blast radius: one record, listed by name, with what would change. An undo covers the rest - when the shipping bill arrives and the mistake surfaces, the state before the restore is one click away, not a reconstruction project.

What an undo actually requires

An undo is not a feature you can bolt on after the write. It only works if the restore saved the state of every record immediately before overwriting it - automatically, not as an option someone had to remember to tick. In StoreVault, that pre-write copy is taken for every record a restore touches; if it cannot be taken, the record is left untouched and the report says so. A restore without a path back is an operation the merchant did not sign up for.

An honest undo also admits its limits. A recreated record got a new ID - undoing the restore removes nothing, because deleting records from a live store is not something a backup app should ever do on its own. The report has to say which records those are.

Questions to ask any backup app, including ours

Before you trust a restore button, find out: Does it show the exact change list before writing, with counts for "already matches" and "missing"? Does it skip records that changed after you approved the plan, and tell you? Is the state before every write saved automatically? Is the undo per restore, and what does it honestly not cover? What happens if the restore is interrupted halfway - does the report show what was already written?

Our own answers, with the boundaries stated plainly, are on what backup apps can and cannot restore and in the FAQ. For the recovery playbook after a bad bulk edit, see how to undo a bulk product edit.