The restore drill report: a live store, damaged on purpose
Last updated 16 September 2026
This is not a description of what StoreVault is meant to do. A set of products and collections was created in a real Shopify store we own, backed up by the same code that runs in production, then deleted and overwritten in that store, and restored. Every claim we publish about restoring was then checked against what the store actually returned, field by field. Twelve claims were exercised and twelve matched - first on a 24-record fixture set on 26 August 2026, then again at 500 records on 30 August 2026; the numbers below are from the 500-record run. One claim has changed since those runs, and row 7 says how. A claim that failed would be listed here with the evidence, not removed.
What happened, in numbers
| Fixtures created in a real store | 500 products, 2 collections |
| Deleted in the first wave | 40 products and both collections |
| Overwritten in the first wave | 60 products: title, description, vendor, type, status, tags, SEO, price, compare-at price |
| Recreated by the restore | 40, every backed-up field identical |
| Restored in place, same product ID | 60 |
| Deleted in the whole-catalogue wave | 500, all of them at once |
| Recreated after the whole-catalogue wave | 500 |
| Whole catalogue back in | 20.3 minutes measured: 2.43 seconds per record |
Claim by claim
| # | What we publish | What the store actually did |
|---|---|---|
| 1 | A restore recreates the product from the version you choose: title, description, price, options, variants, metafields, SEO fields. | All 40 deleted products came back with every backed-up field identical, including price, compare-at price and SKU. |
| 2 | It comes back under a new product ID, and the report says so plainly. | Every one of the 40 is reported as recreated, under a new product ID named in the report. |
| 3 | Overwritten records come back to their previous state. | All 60 came back in place, same product ID, every field identical. |
| 4 | Each of those is written only after a plan you approved, record by record. | Building the plan changed nothing in the store and named exactly the damage: 40 to recreate, 60 to change, 421 untouched. |
| 5 | Records outside the plan are not touched. | 21 pre-existing products and 400 undamaged fixtures came out unchanged, and none of them appears in the apply report. |
| 6 | Collections are restored back into the store. | Both deleted collections came back: the hand-picked one with title and description, the automated one with its rules. |
| 7 | Which products sit in a hand-picked collection comes back with the collection. | Not in this run, and the row says so: on 30 August the recreated hand-picked collection came back empty (it had 100 members), which is what we published then. Membership restore shipped on 16 September 2026 with its own drill, below: 4 of 4 products back in place, 3 of 4 in a recreated collection whose fourth product no longer existed, named in the receipt. |
| 8 | An automated collection keeps its conditions, so the store fills it in again. | The rules came back byte for byte and the store refilled the collection. |
| 9 | Product images and other media are not re-attached by a restore. | The recreated products came back with no media attached, exactly as we publish. |
| 10 | Each restore can be undone: undo returns what the restore overwrote and does not delete what it recreated. | Undo put 60 overwritten records back to the state the restore had replaced and left all 40 recreated records in place. |
| 11 | The backup has been read back, and a drill emails a receipt. | The drill read stored records back from storage and reported integrity ok before any damage was done. |
| 12 | A catalogue deleted all at once can be put back from a plan for an earlier moment. | All 500 products came back after the whole fixture catalogue was deleted in one go: 20.3 minutes, 2.43 seconds per record. |
Row 9 is a limitation rather than a feature, and rows like it are the reason this page is worth reading: media files do not come back, we say so before you buy, and the drill confirms that what we say is what happens. Row 7 was the second limitation until 16 September 2026, when a restore started putting products back into hand-picked collections; the membership drill below is the evidence.
What this run does not prove
- Orders and customers. They are archived and exportable, never written back into a store, so there was nothing to restore and nothing was tried.
- Themes. Not part of this catalogue run - they have their own drill, below.
- Stock levels. Restorable on paid plans through a plan you approve. This run stayed inside the catalogue and did not touch stock.
- Scale beyond 500. The 2.43 seconds per record is a measurement at 500 records (it was 2.96 at 24, so the rate does not degrade with size in the measured range). For a 5,000-product store that works out to roughly three and a half hours - an extrapolation ten times beyond the measured size, and we label it as one. The restore pauses and resumes itself across that span rather than timing out.
Theme drill: 8 September 2026
Theme files get their own run, because they are written through a different API and under a different permission. Shopify approved our exemption request for the Asset and Theme API on 7 September 2026 for one use case: writing files back into a theme that is already installed. We cannot create a theme and we cannot publish one - that limit is Shopify’s rule 1.1.3, it stays, and our own deploy refuses to ship code that calls either.
The run on 8 September 2026 took a theme with 350 files on a store we own, backed it up with production code, overwrote three stylesheets with junk the way another app or a careless edit would, then restored from the snapshot through the ordinary path: a plan naming every file, an approval, an apply, a receipt. The plan named exactly the three damaged files and left the other 347 alone. After the write we read the theme back from Shopify and compared checksums: all three matched the snapshot byte for byte, and the file count was unchanged at 350.
Two boundaries the same run shows. A restore writes files back; it does not delete files that were added to the theme after the snapshot. And if the theme itself is gone from the store, there is nowhere to write: we do not recreate it, and the .zip download of any stored version stays the path for that case.
Collection membership drill: 16 September 2026
Until 16 September 2026 a restore brought a deleted hand-picked collection back with its title and description but without its products, and row 7 above recorded exactly that. A restore now puts the products back, and the new code got its own run on a store we own, through the path a merchant uses: a plan, an apply, and a receipt that reads each collection back from the store after the write.
The run created six draft products and three hand-picked collections, backed them up with production code, then damaged them the way a busy week does: products taken out of two collections, a product added to one of them after the backup, three products deleted and one collection deleted outright. One deleted product was restored first on its own, the way you fix the loudest problem first. Then one plan restored another deleted product and all three collections. Before anything was written, the plan said 8 of the 10 products those collections held in the backup would go back in, and 1 could not, because that product no longer existed.
What Shopify returned afterwards, products matched by title because a recreated product has a new ID:
- Collection restored in place: 4 of 4 products back. Two of them had been deleted and recreated, one by the earlier restore and one by the same plan, and went back in under their new IDs.
- Collection deleted and recreated: 3 of 4 products back. The fourth had been deleted and not restored, so there was nothing to add; the receipt named it and marked the collection as partly restored.
- Collection with a product added after the backup: 2 of 2 products back, and the added product stayed. Products added by hand after the backup stay in the collection, and the receipt says so.
Two more things the same run checked. Restoring a product in place left it in its collections: that write does not touch which collections a product sits in. And undoing the restore left every product it had added in its collection: an undo leaves in place the products a restore added by hand, and the restore screen says so next to the undo button.
What stays out of reach is unchanged: product images and other media are not re-attached, and a deleted collection comes back under a new ID, so links to the old one break.
How the run works
The drill is a command in our own repository, not a hand-made demonstration. It seeds the fixtures, backs them up with production code, records the truth by reading the store itself, damages the catalogue, reconciles, builds a plan for the moment before the damage, applies it, compares the result with the truth field by field, undoes the restore, then deletes the whole fixture catalogue at once and restores that too. It refuses to start unless the store it reaches answers with the domain it was told to expect, and it cleans its fixtures out of the store afterwards.
The run is repeated after changes to the restore code. It has found real defects: on one run the undo failed to clear a compare-at price, because a field that was empty in the backup was being skipped rather than cleared. That was fixed the same day, and the drill is how it was caught.
Related
What backup apps can and cannot restore is the full boundary list. Restore or fix forward is when to use a restore at all, and what to freeze before BFCM is the calendar around it. The compared guide puts the vendors side by side.
A backup app covers you from the day it is installed, not from the day you need it. That is true of all of them, ours included.
StoreVault on the Shopify App Store - versioned backups of products, collections, content and themes, plus inventory levels on paid plans, with a plan shown before any restore writes.