Creating a backup of critical data outside the snap directory

Hey Guys,

our latest snap release was rejected because we added the new critical interface system-files to store backup data outside the snap confinement:

plugs:
  backup-dir:
    interface: system-files
    write:
      - /var/backups/diode-node

Before opening a request for this interface I wanted to check if there is a different way to achieve the same goal. We got this user request If "snap delete" is used, create a snapshot of the critical elements required to resurrect the node · Issue #2 · diodechain/diode_node · GitHub asking for an external auto backup - in addition to the existing snap snaphots which unfortunately are auto-deleted after 31 days even if there is no other backup.

Looking at Create data snapshots - Snap documentation i couldn’t see a away to keep certain data save without explicit user interaction.

Let me know if I’m missing something or a good top/trick to store a minimal amount of data in a snap removal save way. Cheers!

You should check out Accessing resources - Supported snap hooks - Snap documentation regarding access during the hook’s runtime.

Also why writing the backup to /var/backups instead of paths accepted by the removable-media interface like /mnt/...?

If you mean “snap remove”, my snap “shareandcollaborate-com” leaves a Home/shareandcollaborate-com folder behind, so users can re-install or upgrade, and the data is all stored there and doesn’t get deleted. You can get the sourcecode at the link on the home page at shareandcollaborate.com and see how I do it. I hope that helps! -Todd

1 Like

Not sure if you saw this sentence:

Apart from on Ubuntu Core devices, where the feature is disabled by default, 
a snapshot is generated automatically when a snap is removed. 
These snapshots are retained for 31 days before being deleted automatically.

So you could simply use the snap’s built in backup service and probably show a popup that points them to the fact that they can extend the retention period if they want to keep the backup permanently:

Automatic snapshot retention time is configured with the snapshots.automatic.retention 
system option. The value needs to be greater than 24 hours:

1/ About access:

From what I understand,

Hooks can only access snap data area, not outside. They run as ‘root’ so even a ‘home’ plug would be useless as not readable/writable without special authorization. (Plus, ‘home’ interface is not automatic…)

So I think there is only the option of using ‘removable-media’ interface to access data outside of snap data area.

2/ About automatic:

But this interface is not automatic without special authorization ; the user must enter the snap cmd to activate the interface.

Furthermore, your app seems to be a service/daemon, so it runs as ‘root’ and thus can only read/write folders owned by ‘root’.

What makes you think that ? If you remove any snap on a server or desktop system all snap owned data is automatically backed up as snapshot and kept for a month… Only if a user wants to extend that time they need to adjust the snap system config for it (and for that I was suggesting showing a message to the user)…

@ogra

I speak about ‘removable-media’ interface that has no auto-connect:

Right, removable-media doesn’t automatically connect but a writable system-files interface into /var/backups won’t either (I highly doubt the reviewers would allow this if it isn’t essential to run the app)

You will have to communicate that interface requirement to the user somehow in which case you could as well just use the built in mechanism and tell your users about it (and how to keep the snapshot around), that even saves you from having to handle it at all inside the app (a new snap install will just put the snapshot back in place no need for any code in the app)