Reinstalling an app and recovering its earlier working data are separate tasks. Before restoring a Snap snapshot, decide which state you need back and what has changed since then. A successful recovery should preserve that distinction rather than silently replace newer work.

Find the relevant saved set

Run snap saved and identify the app, set ID, age and version. A set can include several snaps. Automatic removal snapshots normally last 31 days; retention settings can differ, and --purge removal skips them.

For example, suppose a removed app held project presets, while its exported documents lived in Documents. List the presets you expect to recover and keep the current exports separately. Note a recognisable harmless preset and its expected value so you can check the result without guessing from the app's appearance.

Snapshots cover snapd-managed user, system and configuration data, subject to exclusions; external documents are outside that scope. From snapd 2.77, mounted filesystems beneath these data directories are excluded too. An administrator can verify the chosen set's integrity with snap check-snapshot.

Plan the overwrite before restoring

Restoration requires the app to be installed, its windows closed and its services stopped. Scope the restore to the intended snap and users. Restoring replaces current saved data, including common data; unlike a revision revert, it can roll that data back.

Preserve any newer presets or records before proceeding. If the application cannot open an older state safely, ask its maintainer for a supported recovery route. Keep the selected set ID and the recovery decision with your maintenance note.

Afterwards, inspect the known preset, open one expected project and save a disposable example. Check the separate exports against your inventory. Snapshot integrity and a completed restore command do not establish that this working set is usable. Keep the original recovery evidence until those application checks pass.

Sources: Snap documentation.