What Shopify backup apps can and cannot restore

Why this list exists

Every backup app on this platform works through the same Shopify API, so the boundary between "can be written back" and "can only be archived" is not a feature difference - it is a property of the platform. Apps differ in whether they tell you.

This is our list, for our product. Check any other app against the same questions.

Restored back into the store

Products with their variants, options, prices and metafields. Collections, including which products sit in a hand-picked collection. Pages: title, handle, body, visibility and metafields come back, and anything a theme or another app keeps alongside the page stays as it is now. Metafields on the records we cover. Stock levels per location, on paid plans, as a physical count.

After a write we read the record back from your store and compare it with the backup. Anything not fully verified is reported as partial or unverified rather than as success, and a record we could not read or compare before writing is left untouched and named in the result.

Each of those is written only after a plan you approved, record by record, and what a restore overwrote in products, collections, pages and theme files can be undone afterwards. Stock levels are not part of the undo: the result lists each level with its before and after numbers, so you can set them back yourself. An undo puts back the theme files a restore rewrote, but a file it added to a theme stays, and so do records a restore had to recreate, because undoing them would mean deleting from your store.

Cost per item comes back on every plan from product versions stored since 18 September 2026, on a product restored in place and on one created again after deletion. A version stored before then does not hold it: restoring one leaves cost per item as it is, and a product created again from it comes back without one.

Deleted products and collections come back under a new ID. The web address (handle) comes back with them when no other record has taken it; when one has, the record still comes back, at a new address with a suffix, and the result names it. A product goes back on the Online Store if the backup shows it was there and you have allowed publishing on the Restore screen, from product versions stored since 18 September 2026. A collection does the same only in a store that allowed publishing, from versions stored after that. Anything else comes back unpublished in every sales channel, and other sales channels are not restored.

Hand-picked collections. Since 16 September 2026 a restore puts the products back into the collection, then reads the collection back from your store, so the result counts what is really in it. A product that was deleted and restored goes back in under its new ID, whether it was restored in the same plan or earlier. A product that no longer exists cannot be added, and the result says how many. A collection sorted by hand gets its products back in their saved order, read back from your store; products added after the backup come after them. Products you added to a collection by hand after the backup stay in it. Rules and exclusions come back exactly as they were in the backup, so a product that a restored exclusion leaves out is left out again. Undoing a restore puts rules back as they were before it; products it added or excluded by hand stay that way.

Archived and exportable, but never written back

Orders. Shopify does not let an app recreate an order as it was - the financial record, the timeline, the payment state cannot be reconstructed from outside. An app that offers to "restore" orders is creating new ones that look similar, which is worse than saying no.

Customers. Same reason, plus the privacy one: a deleted customer who is recreated by an app is a deletion request that did not stick.

Both are kept in full, compared on every drill, and exportable as JSONL whenever you want them. "In full" has a precondition worth checking on any app: reading orders normally shows only the last 60 days, and the full history needs a separate approval from Shopify.

Stored, with a boundary on how they come back

Themes. A version per change, kept as far back as your plan’s history window. Since 8 September 2026 a restore writes theme files back into the theme they came from, after you grant permission to edit themes and approve a plan that names every file. What stays out of reach is creating a theme and publishing one: publishing is the most visible action on a storefront, and doing it from a backup without you watching is not a risk we take. If the theme itself is gone, download the version as a .zip and upload it in the admin. Restores applied before 17 September 2026 did not save theme files before writing, so their undo leaves theme files as they are.

Collection versions stored before 17 September 2026. Until that day our backup did not capture Shopify’s newer collection features: more than one source of products in a collection, excluded products, and conditions mixed with hand-picked products. Restoring a version stored before then brings back the collection’s title, description and products, not those parts. Versions stored from that day on come back in full.

Blogs, articles, menus and URL redirects. Backed up, searchable and exportable; not written back yet.

Not restored at all

Product images and other media. Captured with their metadata and included in exports, but a restore does not re-attach them. A collection picture is captured the same way, and the collection image is not written back either.

Anything the API does not expose. If Shopify does not let an app read it, no backup app has it, whatever the marketing page says.

The questions worth asking any vendor

Does it keep versions per record, or one snapshot that overwrites the last? Does it show a plan before writing? Can a restore be undone? Has the backup ever been read back, and can you see the result? What happens to your data when you uninstall, and how fast can you get it erased on request?

Our answers are in how it works and on the restore drills page. Why the plan and the undo matter more than any other item on that list is a story of its own: why a restore needs a plan first, and an undo after.