Automatic snapshot opt out?

snapd
1

Hi,

Is there a way for a snap to opt out of automatic snapshots? In the case of MicroK8s the removal of the snap is often impossible since the snap may have accumulated several GB of images under SNAP_COMMON. Users report removing the snap takes hours before they run out of disk space. The snap remove --purge is nice to have. It would be great if the snap could specify in its snapcraft.yaml some paths to ignore during snapshot.

Thanks.

1 Like
2

@chipaca it would be great if you could start thinking on suggestions in this area

3

:+1:, Multipass is in the same boat. Each instance tends to be gigabytes in size. But we also have cached images, snapshotting which is just wasteful. We would at least want to exclude the caches from snapshots.

Even better, if the underlying storage is something snapshot-capable (ZFS, btrfs…) it would be nice to use that for the feature.

4

Two approaches fit with what we’ve been doing:

  1. in snap.yaml,
    snapshots:
  ignore-paths:
    - $SNAP_COMMON/foo/bar
    - $SNAP_USER_DATA/foo/baz
  ignore-configs:
    - foo.bar
  2. have snapctl snapshot-paths or something that would let a hook manipulate what gets snapshotted.

The problem with (1) is that it requires some level of care and omniscience on the part of the developer. The problem with (2) is that it’s unclear to me how a hook would look at user data.

5

Why do you consider this a problem? It seems reasonable that snap developers using for example $SNAP_COMMON/foo/bar know what will end-up there. Could you give me an example where this is not the case? If the developer is unsure what goes under $SNAP_COMMON/foo/bar why would she add it in the ignore list.

6

it isn’t necessarily a problem, but it means your program can’t have the user tag what they get to back up, for example (say it’s a video editing software and the app lets the user configure a scratch directory that isn’t backed up, you’d be stopping that use case)

7

Any news on this one?

8

Remark, we do run the “remove” hook afaict before doing the snapshot, so a workaround would be to drop any “low value” but expensive to backup data there.

9

We could consider implementing to start some variant of 1., we need to clarify syntax though. It could still cover obvious cases like when the snap has well-known cache locations.

No timeline on that though.

10

I am testing this workaround right now.

11

The workaround is merged, thanks @pedronis https://github.com/ubuntu/microk8s/pull/542

The critical point was to understand that the remove hook runs before the snapshot.