StoreVault app: Shopify Backups to Undo a Bad Edit or Import, and What It Restores

The Quick Verdict

Find your own case in column one. Every answer rests on StoreVault's listing and pages, Shopify's documentation, or the restore test we ran — all of it below.

What Does StoreVault Cost?

StoreVault's three paid plans differ from each other on two limits only. Its FAQ answers the question Do you charge by orders? with a flat no: a plan sets how many products are covered and how far back the version history goes. The four plan tiers on its App Store listing, read on September 21, 2026, with each paid tier shown again at a founding price:

Source: StoreVault's Shopify App Store listing and storevault.app/founding, both read September 21, 2026; the two state the same limits. Prices in USD, billed every 30 days; the three paid plans carry a 14-day free trial. Founding prices apply only to the first 100 stores that pay.

StoreVault's founding page says the half price lasts for as long as the subscription is active, including through later price changes, and that a place is claimed by the first payment rather than by starting the 14-day free trial each paid plan carries. There is no end date, only a cap — the first 100 stores that pay — and the Founding prices were listed as of September 21, 2026.

Priced by Catalog, Not by Orders

Rewind Backups and BackupMaster both start at $19 a month for up to 300 orders at their entry tiers, as listed on September 21, 2026. StoreVault ignores your order count entirely, so a store selling well past that order ceiling with more than 50 and up to 1,000 products fits StoreVault's $9 Starter plan instead.

Price is only half of that comparison. The apps back up and restore different things — Rewind Backups' own help page lists orders among the records it backs up but cannot restore automatically, and StoreVault says Shopify does not let an app recreate an order as it was — so compare what comes back before you compare what it costs. The pricing axis of the six backup listings we read:

Pricing axis and free-plan terms read on each app's Shopify App Store listing, September 21, 2026. An axis comparison, not a ranking: the apps back up and restore different things.

What Happens If You Downgrade or Uninstall

Leaving a backup app is part of choosing one, and StoreVault's pages, all vendor statements, spell out three exit terms:

• Downgrading or stopping payment doesn't lock your data: the founding page says access to what is already backed up never depends on the plan.
• Version history follows the plan's window — 7 days on Free, 30 to 365 days on paid plans — but the FAQ says the most recent version of every record is kept whatever the plan.
• Uninstalling starts a countdown of about four weeks: Shopify confirms the uninstall 48 hours after it happens, and a 25-day countdown to complete erasure starts from that confirmation.

Can You Trust a Backup App This New?

A backup app is insurance you only find out about in an emergency, so its record matters more than most. StoreVault launched on August 14, 2026, about five weeks before this article was published on September 21, 2026, and its listing showed 0 reviews as of September 21, 2026. We found no independent review or test of it outside Steadyware's own pages and the App Store listing — the search behind that sentence is in the box at the end of the limits section.

Why the Listing Has No Built for Shopify Badge

The badge is missing from StoreVault's listing, and that follows from Shopify's minimums rather than from any verdict. Shopify's requirements say an app must have a minimum of 50 net installs from active shops on paid plans and a minimum of five reviews, and an app with no reviews cannot meet the second.

The badge also stands for the performance, design and integration standard it advertises, and the missing badge tells you nothing about how StoreVault would do on that standard. Whether a new app can carry the badge at all is covered in our guide to the badge.

What StoreVault Asks Permission to Access

Before installing, read the permission list on the listing. StoreVault's, read September 21, 2026, asks for:

• Customer data — name, email address, phone number and physical address, plus geolocation, IP address, browser and operating system
• Edit access to inventory, products and collections
• All order history
• Edit access to the theme and Online Store pages
• Staff data — the store owner's name, email address, phone number and physical address, and blog contributors' email address, IP address, browser and operating system
• Edit access to locations, Online Store navigation and publications of products on sales channels — the last of these is the optional publishing permission we allowed during our test

A backup app needs wide read access to copy a store and write access to put records back. What a permission screen like this grants an installed app has its own short answer.

In our Free-plan test on a development store, restoring theme files took one more step. StoreVault asked us to Allow theme edits, which opened a separate Shopify screen to update its data access to the theme, and theme files were not selected in the restore form by default.

Publishing is a second optional permission. In our test the Restore screen offered Allow publishing, which opened Shopify's screen to update the app's access to publications of products on sales channels; the screen's own words are that products and collections that had to be created again come back unpublished, and that with the permission those that were on the Online Store in the backup go back there.

On data handling, every claim is the vendor's own. Steadyware's security page says copies are encrypted in transit (TLS) and at rest (AES-256-GCM), with one key per store.

Its backup-app comparison is just as plain about what it lacks: no SOC 2 report and no certification programme. It says a store that must answer a vendor questionnaire with audit numbers should pick a vendor that has them.

Our own test· September 18, 2026

What Happened When We Ran a Restore

Key takeaway

We found no independent test of StoreVault, so we ran one on September 18, 2026. We installed it from the App Store on the Free plan, the way any merchant would and with no test access from the vendor, on a Shopify development store holding 49 products — 32 test products we created plus 17 sample products — and 5 collections.

Two settings shape what follows. Before taking our baseline we allowed the app's optional publishing permission on the Restore screen, and every product we later damaged had a version stored that day, which a bulk edit of the test products before the baseline saw to — StoreVault ties publication and Cost per item on recreated records to both, as the limits section explains.

Every result was checked in Shopify's own admin, not StoreVault's reports: a snapshot of every product, collection and the theme file taken before the damage, after it, after the restore and after the undo, down to each variant's Cost per item. No other app was involved.

What this test did not test

• Inventory, which StoreVault backs up and restores only on paid plans.
• Paid plans: the test used Free, so what a paid plan restores rests on StoreVault's pages.
• Scale: 49 products is not the 500 of the vendor's drill.
• Orders and customers, which StoreVault doesn't write back.
• Deleting a whole theme, uninstalling the app, and how long data is kept afterwards.
• Markets, translations, metaobjects and multi-source collections.
• The storefront itself: it was password-protected, so publication was checked in the admin only.

The First Backup and Its Proof Check

Key takeaway

StoreVault's pitch is proof. Its site says it re-reads stored copies, decrypts them, compares a sample with your live store and emails you the receipt whether the check passed or not.

In our test the first full backup started right after installation and took 29 seconds, checking 76 records. The first proof check followed about 11 minutes after the backup started and passed: 57 files checked, 35 records compared, 0 differences, with Articles and URL redirects listed as not checked. The app showed the receipt as emailed about a minute later; we read the result in the app, not in the inbox.

That first check ran on installation; the rhythm afterwards is set by plan. The listing, read September 21, 2026, promises a monthly restore-drill receipt on Free and weekly receipts on Starter, Growth and Pro.

That promise is rarer than it sounds. Of the six backup-app listings we read on September 21, 2026, StoreVault's was the only one whose own description promises a regular check that the copy opens — the search boundary is in the box at the end of the limits section.

The Plan You Approve Before Anything Is Written

Key takeaway

Next we damaged the store on purpose, the way a bad import or a careless edit would:

• Overwrote 8 products by CSV import, changing Cost per item on 4 of them.
• Deleted 6 products, 3 of them members of a hand-picked collection.
• Removed 2 more products from that collection and added 1 product created after the backup.
• Deleted a rule-based collection.
• Overwrote one theme stylesheet with junk.

A StoreVault restore starts with a dry run that shows a plan before anything is written. Ours matched the damage exactly and named nothing we hadn't touched:

Zoom

Applying the plan wrote 17 of 17 records, and the receipt appeared within a minute of the click. The warning on the plan screen is worth reading before you apply one: records missing from the store come back as new records with new IDs, not under their old ones, where StoreVault can create them again.

Two lines on the plan matter for what comes next: that 7 recreated records — the 6 products and the collection — were on the Online Store in the backup and go back there, and that the theme is saved before writing so that undoing the restore puts back the theme files it rewrites.

What Came Back, Field by Field

Key takeaway

We compared the restored store with the snapshot taken before the damage, field by field. The third column sets each result against StoreVault's description where it gives one; the four results that depend on a date its pages name are taken apart in the limits section:

Our restore, checked against Shopify's own admin

What we damaged or checked	What came back in our test	Matches StoreVault's description?
8 overwritten products	Every field we compared in the admin back to the pre-damage state — titles, prices, compare-at prices, vendor, tags, SEO, status, and Cost per item on the 4 products whose cost we had changed — under the same product and variant IDs	Yes
6 deleted products	Recreated with new product and variant IDs; handle, title, description, vendor, type, tags, status, options, SKUs, prices, compare-at prices, SEO fields and Cost per item matched, and all 6 came back published to the Online Store, since we had allowed publishing before the backup	Yes, as StoreVault's page read September 18, 2026 describes: publication and Cost per item come from product versions stored since that day — see the four dated limits below
Images on those 6 products	0 came back	Yes — a restore does not re-attach media
Hand-picked collection members	12 of 12 back, 3 of them under new IDs, in their saved order position for position; the product added after the backup came 13th, and the receipt said so	Yes — the restore screen counts the members, and StoreVault's page read September 18, 2026 describes the saved order
Deleted rule-based collection	Recreated with a new ID, the same handle and the same tag rule, holding the 9 products its rule matched, and published to the Online Store	Yes
One overwritten theme stylesheet	Written back and read back identical to the pre-damage copy	Yes
Handles of recreated records	Reused — all 6 products and the collection got their old handles back	Yes — StoreVault's restore-limits page, read September 21, 2026, says the handle comes back when no other record has taken it, and otherwise the record returns at a new address with a suffix that the result names; no shopify.dev page we read documents handle reuse
Undo of the restore	10 of 10 records written: the 8 overwritten products returned to their state just before the restore, Cost per item included; the undo plan named the theme file, and the file went back to its pre-restore contents	Yes — the restore plan says the theme is saved before writing, and StoreVault's page ties that to restores applied since September 17, 2026
What undo left alone	The 6 recreated products stayed, and the 5 products returned to the hand-picked collection stayed in it, listed after the 8 it held just before the restore	Yes — the restore screen says products it added to a collection stay

One test on a Shopify development store, StoreVault Free plan, 49 products and 5 collections, September 18, 2026, after allowing publishing on the Restore screen and with product versions stored that day; every result read in the Shopify admin, down to each variant's Cost per item. No other app.

The handle row matters for links, because Shopify builds a product's online store URL from its handle. A recreated product that gets its old handle back should answer at its old address, but we couldn't confirm it on the password-protected storefront — check the URLs of your important products after a restore. Our six got their handles back because nothing else had taken them; StoreVault's restore-limits page, read September 21, 2026, says that when another record has taken the address in the meantime, the recreated record comes back at a new address with a suffix, and the result names it — so a link to the old address no longer reaches that product.

What StoreVault Doesn't Restore

Two kinds of limits follow. The first set StoreVault publishes as things a restore never does, and Shopify's documentation explains most of them; the second set is four results that depend on a date — what its pages say, what our test showed, and what to do if your store sits on the older side of that date.

The Limits StoreVault Publishes

StoreVault keeps a page titled what backup apps can and cannot restore, and it is specific about its own gaps. The one that shapes the rest starts with how Shopify itself treats a deleted product:

So a deleted product can only return as a new record, and what comes back with it depends on the app. Side by side, what StoreVault says it doesn't bring back and what Shopify's documentation says about each:

StoreVault column: storevault.app, read September 18, 2026. Shopify column: shopify.dev and the Shopify Help Center, read September 21, 2026.

StoreVault's restore-limits page also names records it doesn't write back: blogs, articles, menus and URL redirects are backed up and exportable but not written back yet, and customers, like orders, are archived and exportable but never written back.

Images are the limit most stores feel first. Deleting a product through Shopify's API takes its images and videos with it unless another product uses them, so a backup has to put them back rather than find them — what deletion takes from a product that an app has to return is covered in our backup guide. Keep your own image originals whichever plan you pick.

Don't assume another app closes that gap. In the descriptions of the other five backup listings we read on September 21, 2026, none names product images as something it backs up or restores, so a listing alone won't tell you.

StoreVault also says, on that page as read on September 18, 2026, that collection versions it stored before September 17, 2026 don't include more than one source of products, excluded products or conditions mixed with hand-picked products; restoring one brings back the title, description and products, not those parts. StoreVault says versions stored from that day on come back in full; our test did not cover such collections. If you use Shopify's multi-source collections and restore one from such an earlier version, rebuild those rules by hand.

Four Limits to Know Before Your First Restore

StoreVault's restore-limits page, FAQ and help, read September 18, 2026, carry a sentence on each of four results a restore can produce, three of them tied to a date. Our test ran on the newer side of every date — publishing allowed before the backup, product versions stored the same day, the restore applied that day — so what it shows is the app with those conditions met. What each sentence says, what we saw, and what to do if your store sits on the older side:

Our column: one test on a Shopify development store, StoreVault Free plan, 49 products, September 18, 2026, after allowing publishing on the Restore screen and with product versions stored that day. StoreVault column: its restore-limits page, FAQ and help, read September 18, 2026, paraphrased; the page's own sentences are quoted below the table.

The condition column paraphrases. In StoreVault's own words, from its restore-limits page as read on September 18, 2026:

• Publication: “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.”
• Cost per item: “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.”
• Collection order: “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.” No date is given for this one.
• Theme files: “Restores applied before 17 September 2026 did not save theme files before writing, so their undo leaves theme files as they are.”

Two cautions keep this table honest. It is one Free-plan test, so we can't say from our own data how a paid plan behaves; StoreVault's page says Cost per item comes back on every plan, and our Free-plan result matched it. And the storefront was password-protected, so publication was read in the admin, where each recreated record showed as published to the Online Store.

Check publishing first. A restore from a version stored before September 18, 2026, or one run without allowing publishing, brings recreated records back unpublished, and a product that isn't published to the Online Store is hidden from your storefront however complete it looks in the admin. Where to check a product's publishing in your admin has its own short answer.

What to Do Before and After a StoreVault Restore

Most of what our test found costs a few minutes of preparation and a checklist afterwards, and the theme file is the one to handle before the restore.

In our test the undo named the restored stylesheet and put its pre-restore contents back, and StoreVault says restores applied before September 17, 2026 leave theme files as they are on undo. Copy the file first anyway, as Shopify advises for its own theme-file restore:

Steps one to three belong before any incident, four to six happen during the restore, seven to nine apply only when the plan recreated deleted records, and ten applies whenever a restore puts products back into a hand-picked collection. Tick them off as you go:

The Bottom Line

StoreVault does the part a backup app is for: in our Free-plan test, the plan named exactly the damage, overwritten products came back field for field, and the undo put back what the restore had written. What it doesn't have yet, as of September 21, 2026, is a record — a listing launched on August 14, 2026 with no reviews, a drill report written by its own vendor, and one independent test, ours — we searched again on September 21, 2026 and found no other.

What it does publish is the boundary of that result: publication and Cost per item on recreated records come from product versions stored since September 18, 2026 — publication only with the permission allowed on the Restore screen — and theme-file undo covers restores applied since September 17, 2026. The checklist above spells out the older cases.

Frequently Asked Questions