I’m hoping we can solve this problem by introducing snapshots, which is a first class representation of the storage and data associated with a snap in the system (not just the data). Such snapshots would not include the snap file itself. Only the data in use at a time and metadata for the snap, including the snap configuration, etc.
This is certainly an important stepping stone towards introducing backups, and perhaps most of the functionality as far as snapd is concerned, but I would reserve the term “backup” for something that actually takes the data offsite.
Quick strawman as a hint of what snapshots would be:
| Command | Summary |
|---|---|
snap saved |
Lists currently stored snapshots |
snap save bitcoin |
Take a snapshot of the bitcoin snap |
snap lose bitcoin |
Delete all snapshots of the bitcoin snap |
snap lose bitcoin 32 |
Delete the specific snapshot of bitcoin |
snap squash bitcoin 32 |
Replace data currently in use by bitcoin with snapshot 32 |
snap remove bitcoin |
Remove bitcoin and save current data in a temporary snapshot |
snap purge bitcoin |
Remove bitcoin snap and immediately drop current data |
The temporary snapshot created on remove is maintained for N weeks, and we can allow the snap to define the amount of time to keep that snapshot (edit: spelled as short/medium/long term, see below). The user should be able to turn that snapshot into a persistent one if desired.
How does that sound?