A snap-packaged service on a server started failing immediately after snapd refreshed it to a new revision. How do you get it back onto the previous revision, and what happens to the service's data when you do?

## Revisions are the unit of rollback Every build of a snap that snapd installs carries a **revision** — a store-assigned integer, shown in the `Rev` column of `snap list`, distinct from the upstream version string. snapd does not overwrite in place: a refresh installs the new revision alongside the old one, mounts it, and moves the `current` symlink. That is what makes rollback cheap, and it is the structural difference from a distro package upgrade, where the old files are gone. ```bash snap list --all mysnap ``` This prints every revision snapd is still holding for that snap, with older ones marked `disabled` in the Notes column. Whatever appears there is what you can roll back to. ## The revert itself ```bash sudo snap revert mysnap ``` With no arguments this moves to the revision that was current before the last refresh. snapd stops the snap's services, repoints `current`, and starts them again on the old revision. No network is involved, which matters at 3 a.m. and matters more if the failure is itself network-related. To choose a target explicitly: ```bash sudo snap revert --revision=1042 mysnap ``` And to see what snapd did, `snap changes` lists recent operations with IDs and status, and `snap tasks <id>` expands one of them into its individual steps — useful when a revert reports failure and you need to know which task failed. ## What happens to data This is where candidates who have only read about revert come apart. A snap's writable system data lives in two places: `/var/snap/<name>/<revision>/` (`$SNAP_DATA`), which is **per revision**, and `/var/snap/<name>/common/` (`$SNAP_COMMON`), which is shared by all revisions. Per-user data mirrors this under `~/snap/<name>/<revision>/` and `~/snap/<name>/common/`. On refresh, snapd copies `$SNAP_DATA` from the outgoing revision into the incoming revision's directory, so the new build starts from the old state. On revert, the old revision's directory is used again as it stands. The consequences: - Anything the new revision wrote lives in *its* directory and does not come back with you. Records created in the minutes before you noticed the breakage are still on disk, but the reverted service will not see them. - `$SNAP_COMMON` is shared, so whatever the new revision wrote there **is** still live after the revert. If the new build corrupted a file in common, the revert does not fix it. - An irreversible migration — a database schema upgrade against an external store, or a rewrite of files in common — is untouched by revert, because revert only moves which code and which per-revision directory are current. So the honest answer to "does revert restore my data?" is: it restores the per-revision data as it was at refresh time, and nothing else. ## Stopping it from coming straight back A revert changes which revision runs; it does not by itself express "never give me that build again". On a machine whose snaps refresh automatically, the sensible immediate follow-up is to hold the snap while you investigate: ```bash sudo snap refresh --hold mysnap ``` and `--unhold` when a fixed revision is published. Treat the hold as temporary and tracked, because a held snap also stops receiving security fixes. ## When revert cannot save you Three cases to name: 1. **The revision is gone.** Retention (`refresh.retain`, default 3 on classic systems, minimum 2) decides how many revisions stay on disk. If retention was lowered or several refreshes landed before anyone noticed, the good revision may already have been pruned; then you need `snap install --revision=<N>` from the store, which requires network and requires the store still to serve it. 2. **The damage is outside the snap.** External databases, files in `$SNAP_COMMON`, changes pushed to other systems — none of it is in scope. 3. **The snap is sideloaded.** A snap installed from a local `.snap` file carries `x1`-style revisions and has no earlier store revision to fall back to unless you kept the file. ## Snapshots, the explicit tool For data you actually want to be able to restore, snapd has a separate mechanism: `snap save <name>` captures the snap's data into a snapshot, `snap saved` lists them, `snap restore <set-id>` puts the data back, and `snap forget <set-id>` deletes one. `snap remove` takes a snapshot automatically unless you pass `--purge`. In a change-controlled environment, taking a snapshot before a deliberate refresh gives you a data rollback that `snap revert` alone cannot. ## What the interviewer is testing That you distinguish rolling back **code** from rolling back **state**. `snap revert` is a genuinely excellent code rollback — instant, offline, and structurally guaranteed by the revision model. Believing it is also a data rollback is how a routine incident turns into silent data loss.