we use the snapshot mechanism to create backups of a snap. When restoring the snapshot we first disable the snap, perform the restore and enable it afterwards. This works fine for all snaps except the one that is performing the restore. We can not disable it before running the restore. So we might get some raise condition where snapd is restoring the snap data and the snap itself is writing to snap data. In the worst case we get inconsistent data for the snap.
Is there a away to tell snapd to perform the restore “offline”, meaning that snapd handles the “disable” and “enable” part? Would it make sense to add something like this as an option to the “snapshot” action?
Or is there another best practise way for this use case?
I don’t have a short term answer to this except that it should be possible for the restoring snap (as it is driving this after all) to set itself in such a mode (using a dedicated process or whatever makes sense) such it survives the restore properly without races.
We have longer term ideas about a more fully fledged backup API, that would properly support hooks and other mechanisms that would help with this, but is not on our immediate roadmap.
Another possible approach would be to have ways in the API to combine multiple operations together in a more generic way to compose changes (in this case: disable+restore+enable), but that’s also not on our immediate roadmap.
So I think both approaches would definitely help us. I think the second approach would also help in regard of installing multiple snaps using “sideloading”. Which is a big pain point for us currently.
