# Overview
History is the record of what your live theme has looked like over time. Restore is how you put any of it back. They are one feature: the recording is what makes the restore possible, and the restore is what makes the recording worth having.
If you arrived here looking for *backup* — this is it. Snapty records your live theme's files on a schedule and keeps every version. What it does not promise is whole-and-in-place recovery, and this page says exactly where the edges are.
## How a check works
1. Snapty asks Shopify which theme is published **right now**. It does not trust a stored answer — you may have published a different theme since the last check.
2. It reads every file in that theme.
3. It compares each file with the last recording.
4. If anything differs, it writes a new recording. If nothing differs, it does not.
Either way, the check itself is logged.
**How often:** once a day on the free plan, spread across the day rather than at a fixed hour. The History screen shows when the last check ran — *checked 4 hours ago · every day*.
**Files Snapty cannot read** are marked *unreadable* and kept in the recording, rather than assumed unchanged or left out — a file missing from a recording would read as *deleted* everywhere downstream.
**A check that stops partway through writes no recording.** Half a theme is not a smaller true answer; it is a different theme.
## "Nothing changed" is not "nothing was checked"
**A check that finds nothing writes no new recording.** That is deliberate: a store nobody has touched would otherwise accumulate a recording a day, each identical to the last, and finding the one that mattered would mean scrolling past thirty that did not.
So a timeline that has not moved in three weeks does not mean Snapty has stopped. The [Activity log](https://docs.foxecom.com/snapty-app/history-and-restore/the-activity-log) lists every check, including the ones that found nothing; a row saying **No change** is a check that ran, read your theme, compared every file, and found everything matching. On a healthy store that is most of them.
| | |
| --- | --- |
| **Nothing has changed** | Snapty checked, and every file matched what is recorded |
| **Nothing has been checked** | Snapty has not run — and something could have changed without you knowing |
A timeline alone cannot tell these apart, which is why the activity log exists.
## What a recording is compared against
When you open a recording, it is compared against **the theme it was taken from, as that theme is right now** — not against whatever theme happens to be live today, and not against a pristine copy of the original. That is also where a restore puts things back: what you are reading the differences of is exactly what the restore button writes into. You can change the comparison to any other recording with the picker.
## Retention and roll-off
Recordings are kept for **30 days** from the day they were taken. After that they roll off and can no longer be opened or restored from.
- **You are warned first.** Seven days before your oldest recordings start rolling off, the History screen says so, and Snapty never trims silently.
- **What rolling off does not affect:** your Vault snippets, the activity log, and your live theme. Nothing on your store changes when a recording rolls off.
- **Timelines from a theme you no longer use** age out on the same 30-day clock. Switching your live theme does not delete what came before, and does not extend it.
**Two kinds of recording never roll off, on any plan:**
- **Your baseline**, and every recording taken **before a restore**. The baseline is the point everything is measured from and cannot be recreated once gone; the before-a-restore recordings are what make a restore undoable. Snapty keeps both past the 30-day line, and marks them on the timeline.
- **Recordings you keep.** Press **Keep this snapshot** on any recording and it is exempt from roll-off. The free plan allows **3** kept recordings at a time; release one to keep another. A baseline or before-a-restore recording is already permanent and does not use one of the three.
## Why Snapty never says your theme is fine
Your baseline records your live theme **as it was found** — with whatever was already in it. A tracking script pasted into `theme.liquid` last year is in your baseline. A snippet an app wrote and never removed is in it too. Snapty was not there when it happened.
So *"nothing has changed"* means exactly this: the theme is the same as when Snapty first saw it. It says nothing about what that state was.
| Snapty says | Snapty never says |
| --- | --- |
| Nothing has changed since Snapty started watching | Your theme is clean |
| No differences from your last recording | Your theme is unmodified |
| Every file matched what is recorded | Your theme is eligible for updates |
## Restoring
Two shapes, and they are not variants of one another. They have different targets, they write different things, and only one of them can touch your live theme.
| | Single file | Whole version |
| --- | --- | --- |
| **What goes back** | One file you choose | Every file the recording holds |
| **Where it lands** | The theme the recording came from — in place, or a copy of it | Always a new unpublished copy of that theme |
| **Can it touch your live theme?** | Yes, if you choose that and confirm it | No |
| **Is your theme recorded first?** | Yes, always | Not needed — the target is brand new |
### The rule underneath both
**The recording supplies the files. The theme it was recorded from supplies the target.**
A restore never puts a file into a different theme — not even your live one. A `sections/header.liquid` recorded from one theme refers to settings, snippets and schema another theme may not have; dropping it in produces a broken section on a storefront, the exact thing this feature exists to prevent. If the recording and the target are not the same theme, the restore is refused before anything is read.
### A restore is not a rewind
Restoring puts recorded files **back**. It does not remove anything to make the theme match the recording, in either shape.
- **A file that was changed** → the recorded version comes back. This works.
- **A file that was deleted** → it comes back.
- **A file that was added after the recording** → it stays. If that file is what broke your theme, the restore does not fix it.
Snapty never deletes a file from a theme, because deletion is the one operation another restore cannot undo. For a whole-version restore, the confirm step lists the files the copy will keep, by name, before you go ahead. If the file you are chasing is on that list, remove it yourself in Shopify's theme editor.
### What restore never does
| Never | |
| --- | --- |
| **Publishes** | A restored copy arrives unpublished. You publish it in Shopify, or you do not |
| **Deletes a file** | Adds and overwrites, removes nothing |
| **Writes into a different theme** | Only the theme the recording came from. *"We could not confirm these are the same theme"* is refused too |
| **Touches your live theme unasked** | A whole version cannot target a published theme at all. A single file can, only when you chose your live theme by name and confirmed on a screen that says customers will see it immediately |
| **Reports a write it did not verify** | Shopify answers a write with a job id, not a result. Snapty reads the file back and compares it with what was recorded. **Restored** means the read-back matched |
| **Restores a theme deleted from Shopify** | Both shapes need the theme. The recording stays readable; the theme is what is gone. If a theme's history matters, restore it into a copy before deleting the original |
## Common questions
Because nothing changed. The check is in the activity log.
**Take a snapshot now**, on the History screen. If nothing has changed, Snapty tells you and writes no entry.
Yes — **Keep this snapshot** on the recording. The free plan allows 3 at a time. Your baseline and every before-a-restore recording are kept automatically and do not count.
Still there, marked as no longer your live theme. Turn on **Include what came before this theme** on the History screen.
Only if you restore a single file and explicitly choose your live theme, on a screen that warns you. A whole-version restore never touches a published theme.
A single-file restore into a theme you already have — yes: Snapty records that theme first, tagged **before a restore**. A whole-version restore made a new copy and changed nothing that existed, so there is nothing to undo.
Almost certainly a file added after the recording. A restore deletes nothing, so anything added since survives it. The confirm step listed those files.
No. A file from one theme dropped into another is a broken storefront produced by the feature meant to prevent one.
No. The recording stays readable, but there is nothing to write it into.
No. Snapty does not produce theme files in any form you can take away.
No. There is no limit on how many restores you run.