The restore drill report: a live store, damaged on purpose
Last updated 29 August 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. A claim that failed would be listed here with the evidence, not removed.
What happened, in numbers
| Fixtures created in a real store | 24 products, 2 collections |
| Deleted in the first wave | 6 products and both collections |
| Overwritten in the first wave | 8 products: title, description, vendor, type, status, tags, SEO, price, compare-at price |
| Recreated by the restore | 8 |
| Restored in place, same product ID | 8 |
| Deleted in the whole-catalogue wave | 24, all of them at once |
| Recreated after the whole-catalogue wave | 24 |
| Whole catalogue back in | 71.0 seconds, 2.96 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 6 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 6 is reported as recreated, under a new product ID named in the report. |
| 3 | Overwritten records come back to their previous state. | All 8 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: 6 to recreate, 8 to change, 30 untouched. |
| 5 | Records outside the plan are not touched. | 20 pre-existing products and 10 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 | Manual collection membership is not written back. | The recreated hand-picked collection came back empty, exactly as we publish. It had 14 members before. |
| 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 with 24 products. |
| 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 8 overwritten records back to the state the restore had replaced and left all 6 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 24 products came back after the whole fixture catalogue was deleted in one go. |
Two of those rows are limitations rather than features, and they are the reason this page is worth reading. Manual collection membership and media files do not come back, we say so before you buy, and the drill confirms that what we say is what happens.
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. Kept and downloadable as a .zip that you upload yourself. The app never publishes a theme into a store, so a theme restore cannot be automated here.
- Stock levels. Restorable on paid plans through a plan you approve. This run stayed inside the catalogue and did not touch stock.
- Scale. The catalogue here is a fixture set, not a store with thousands of products. The per-record time is measured; the total for a large store is that number multiplied, which is an estimate and not a measurement.
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.