Restore
Read the change. Then make it.
Every restore produces a field-level preview first, generated by the same plan that will execute it. Nothing is written until you have seen what will be.
Restore
Restoring to 12 Oct
3 changes
| Field | Now | After |
|---|---|---|
| price | 149.00 | 129.00 |
| inventory_level | 12 | 0 |
| is_visible | true | false |
Nothing else is touched, and nothing is deleted.
Why the preview exists
A restore writes to a live store. The failure that matters is not a job that errors — it is a job that succeeds and changes something you did not expect. So the plan is built, shown, and only then run.
It is the same plan both times. A preview assembled by separate code would be a second opinion about what is going to happen, and the one you read would not be the one that runs.
Three depths, none destructive
A restore puts back what was lost. It does not make your store equal to a past moment, because that would mean deleting everything that happened since — the orders, the customers, the reviews.
One record
A product, a page, a customer, returned to a version you picked off its timeline.
Deletes nothing
In bulk
A whole category, or every record of one type, restored in a single job with one preview covering all of it.
Deletes nothing
The whole store
Everything that existed at a moment and is now missing or different is rewritten, in dependency order: brands and categories first, then products, then variants.
Deletes nothing
Recreated records keep their place
A deleted product comes back with a new BigCommerce id. Everything that pointed at the old one — variants, images, category membership, price list records — is remapped to the new id as part of the same job, so a restored product is whole rather than merely present.
Jobs survive interruption
A full-store restore on a large catalogue runs inside a shared API quota, so it will be throttled. Every job checkpoints: it resumes where it stopped rather than starting again, and the progress you watch is the real position, not an estimate.