What Shopify Backup and Restore Actually Covers
Ask most Shopify merchants whether they have a backup and you'll get one of two answers: "Shopify handles that, right?" or "Yes, I'm using [app name]." Both answers tend to hide the same gap: a vague confidence that something is being saved, without a clear picture of what exactly.
The reality is that Shopify backup tools — including Vaultkeep — operate within limits set by Shopify's API. What gets covered, and what doesn't, is worth understanding before you actually need to restore something.
What "backup" means in the Shopify context
A Shopify store is not a single database you can snapshot. It's a collection of resources — products, collections, pages, customer records, theme files, metafields, redirects, navigation menus, store policies — each accessible through Shopify's Admin API.
A backup tool reads those resources through the API on a schedule and stores the data. A restore tool writes those resources back through the same API. The boundary of what's possible is defined entirely by what Shopify exposes and what it allows to be re-created.
That shapes what good backup coverage looks like in practice.
What Vaultkeep backs up
Vaultkeep captures a broad range of store resources on a daily schedule. These include:
Products and variants. Product titles, descriptions, images, variants, pricing, inventory quantities, metafields, and associated collections. This is the core of most merchants' stores, and it's fully restorable — you can bring back a product that was accidentally deleted, or revert a bulk price update that went wrong.
Collections. Both manual and smart collections, including their conditions, sort orders, and product associations.
Pages and blogs. Static pages (About, FAQ, Contact, custom pages) and blog posts. These are often overlooked until a theme switch or accidental deletion removes them.
Customers. Customer records including contact details, addresses, tags, and account status. Note: order history is associated with customers but restoring a customer record does not restore their orders — see below.
Redirects. URL redirects are stored and restorable. This matters if you're migrating content or restructuring your catalog and don't want to lose SEO value from old URLs.
Navigation menus. Storefront menus and their link structure.
Store policies. Refund policy, privacy policy, shipping policy, and terms of service.
Theme files. The current theme's template, section, and asset files — so if a theme edit breaks something, you can restore the file to a previous state.
This covers the configuration and content layer of a store. For merchants managing a catalog, maintaining custom pages, or working with teams who can accidentally modify things, this is the data that needs protection.
What can't be restored — and why
There are three resource types that Vaultkeep captures but cannot restore: orders, draft orders, and abandoned checkouts.
This isn't a product limitation — it's an API limitation. Shopify does not provide a way to create or recreate orders through the Admin API in the way that would be required for a true restore. Orders exist in a regulated financial context; the platform intentionally prevents external tools from writing new order records.
What this means in practice: Vaultkeep records order data so you have a snapshot of your transaction history, but if orders are somehow lost or corrupted on Shopify's side, that data cannot be used to recreate them through the API.
For most merchants, this is not the risk scenario they're worried about — Shopify's own infrastructure is responsible for order data integrity. The cases where backups provide the most value are things like accidental bulk edits, theme file overwrites, deleted products, or a staff member removing content. Those are all restorable.
It's worth being direct about this because some backup tools aren't, and a merchant who assumes their backup covers "everything" can be caught off guard.
Granular restore vs. full restore
One of the more practical features of a backup system is the ability to restore individual items without reverting the entire store.
If a product's description was overwritten by an import that went wrong, you want to restore that product to yesterday's version — not roll back every other product, page, and collection to a prior state.
Vaultkeep stores each resource with version history, so you can identify the version you want and restore just that item. A store clone is also available for cases where you want to test a significant change — like a theme overhaul or a catalog restructure — in an isolated environment before touching the live store.
How to think about backup coverage
A useful mental model: Vaultkeep protects against human error and accidental data loss at the content and configuration layer. It doesn't protect against infrastructure failures on Shopify's side (which are Shopify's responsibility), and it can't recreate financial records.
The clearest use cases are:
- Recovering deleted products or collections
- Reverting a bulk update that produced unexpected results
- Restoring a page or blog post that was accidentally removed
- Recovering theme files after a bad edit
- Cloning a store before a major migration or theme change
For teams where multiple people — staff, contractors, apps — have access to the Shopify admin, accidental changes are an operational reality, not a hypothetical.
Finding out what's actually in your backup
The right time to understand what your backup covers is before something goes wrong. If you're evaluating a backup tool or want to know what Vaultkeep has captured for your store, the clearest step is to look at the resource list and review a recent backup snapshot.
If you'd like to learn more or have questions about what Vaultkeep can cover for your store, get in touch.