How to keep data when removing a snap

What is the best way to leave a file/directory behind (not delete) after removing a snap application?

Use case: cryptocurrency wallet where a user could accidentally remove the application and now the wallet file is gone forever. The user would be upset and out of money if he/she doesn’t backup the file.

1 Like

Currently there is no way to do this. Speaking in general it would be awesome if snapd could generate and restore backups. Since we know where the data is already this should not be difficult.

As for your specific question I think it is interesting, it is not (perhaps) immediately clear that removing a snap will remove its data. CC @chipaca

snappy (in 15.04) had separate remove and purge steps for this, but we abandoned that in favour of the current simpler model as it wasn’t well received nor understood.

I agree separate purge is confusing but I’d say that as a user I’d like to be able to remove a snap and keep my data easily, without being a developer. We should explore a story for this.

perhaps adding a --keep-user-data switch to “remove” might make sense (so it is an explicit thing)

We can make many small steps but I think what is needed is good overall experience. The person who lost their wallet would not have used --keep-data without knowing about it.

for that case it might perhaps make more sense to allow snaps to add a Y/N question to the removal process via a snapcraft.yaml option … (seems like we have two bugs here … one to keep data on demand, one to make sure a user doesnt accidentially remove an important snap)

3 Likes

Yes, I was thinking about very-precious-data: bool key imagining snap remove home-family-photo-collection but then again, is there any snap that actually keeps data that is not valuable. Will this option degrade to just true.

Maybe we want $SNAP_PRECIOUS_USER_DATA which is like $SNAP_USER_DATA but is automatically backed up and kept until removed explicitly.

1 Like

Note this is a very old request with specific direction from snappy architects. While I happen personally to agree with the sentiment of the request, if this is going to be revisited, we need an architect to comment and participate in the new direction (cc @niemeyer).

My 2 cents which I guess is similar to zyga

$SNAP_USER_PERMANENT_DATA will store non versioned user data that will persist after removal of the application unless specifically requested to delete via yes/no question, dialog box or command line flag.

snap remove myapp will produce a yes/no question.
snap remove myapp --delete-permanent

1 Like

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?

1 Like

#1 This type of functionality sounds great! Whether it solves this specific problem or not, it should be added.
#2 Will this user even know this functionality is there? What’s the chance a user removes the app and remembers months later (will the backup snapshot be rotated out by then)? What happens a user runs out of space and starts clearing up things like the app and snapshots (as weird as it sounds, so many users clear backups first)?

The functionality is great. I feel giving developers options to create persistent data directories that would be snapshot’d is the best combination/solution.

There’s indeed some tension between never losing important data and never recovering wasted space. For example, it’s easy to argue that if one removes a snap without saving its data, and doesn’t even go after the data at all for a long time, the data was indeed not very relevant and should have been removed in the first place.

So the intent of the proposal is recognizing that and giving a chance for recovery of important data, while at the same time not wasting space forever on unimportant data.

Instead of defining the number of weeks, we should probably support three levels instead: short term, medium term, and long term, and we can then define and polish over time how each of these behaves. We might end up warning people about the long term ones instead of removing straight out, for example.