Archiving Apps

[scooke]

THIS. For real.

[marcusquinn]

@scooke I suppose we should add:
3. Create/Restore an App from a local .zip upload.

[humptydumpty]

I thought you could already do this using the "download backup" option in CR dashboard > app settings > backups. It downloads some tar.gz.enc file. I couldn't figure out how to open it locally.

edit: so there's no way to "upload" that backup from your local machine even if you could download it. There's a "filesystem" option, but I think that means you have to copy that backup to the server before being able to import it. Too much hassle.

[marcusquinn]

@humptydumpty Yeah, I feel it could be a simple UI addition, that would make it good for backing up and decluttering stopped apps, in a way they could be restored again in future if needed, otherwise archived locally to save on more expensive server storage costs.

[jdaviescoates]

I seem to remember when this came up before @girish said not being able to directly upload backups was due to security concerns or something?

[marcusquinn]

Hmmm, seems the feature already exists?!?

Although, I'm not sure what would happen if the downloaded archive were uploaded and the app not to have a matching package version or access control:

Import From External Backup
Use this to migrate an app from another Cloudron. The other app must have the same package version and access control setting as this one.

I can't find any other explanation for what would happen in the docs if the uploaded app differed? @girish

[marcusquinn]

@girish I think my feature request here is:

1. Clarity on what would happen if one were to say try restoring a backup of an older version, without the same access controls as setup on the destination server.
2. For us to have an ability to set specific App backups as persistent, regardless of the retention policy, as an extension to the existing feature that just offers to persist all backups from a specific date-time. This way, one could set an app as persistent in the backups, and delete the app safe in the knowledge it could be later restored if needed.

I have about 30 Apps I'd like to do this for, which would save a lot on expensive VPS storage space, when the S3 compatible cold-storage would be perfectly adequate for retaining archives and decluttering Cloudron instances from these.

[girish]

(I wrote this initially by reading https://forum.cloudron.io/post/93754 . So, didn't pick up the ideas already in this thread)

Wanted to resurrect this thread. Trying to collect the use cases for archiving and what it means to you.

For us, one use case we have is simply: stop app and hide it from the dashboard. Then, this app can later be started/unhidden. This way you preserve all the previous configuration and backups (based on backup policy). It also means that the live data is still around in the server (i.e the app is not uninstalled, just stopped) and you are not just relying on "backups" (in the case where you don't trust the backups).

Side effects of implementing it like above:

• It will block the subdomains for use in other apps. Is this a problem? Maybe we can move the app to "archived" subdomain or something automatically to prevent this? Maybe, we will not create real DNS entries when we do this.
• App Volumes will be blocked

[girish]

@marcusquinn said in Archiving Apps:

Clarity on what would happen if one were to say try restoring a backup of an older version, without the same access controls as setup on the destination server.

It would have the access controls of the destination server. If the original backup had users that are not in the destination server (i.e with Cloudron SSO), such users cannot login. In general, just think of it as what would happen when moving servers without Cloudron in the picture. It's the same that would happen with Cloudron (mostly).

For us to have an ability to set specific App backups as persistent, regardless of the retention policy, as an extension to the existing feature that just offers to persist all backups from a specific date-time. This way, one could set an app as persistent in the backups, and delete the app safe in the knowledge it could be later restored if needed.

I like the idea of just keeping the app around (stopped) but it will disappear from the dashboard. For the user, it's uninstalled for all practical purposes. The main advantage is that since app is actually still there (meaning, there is a database entry for it), you can still tinker with all the backups and their configuration. For example, say you want to change the backup persistent time of a archived app. This is must easier if the app itself was still in the database.

[JLX89]

For the most part, everyone else covered my use case on this.

Either the ability to download the file as a tar.gz, that isn't encrypted to store locally or external storage.

To take this functionality a bit further down the road:

Offload the app and environment settings to an external S3 storage, gui to view these on like the file explorer, view basic details (time offloaded, size, dates, view file contents). There have been times where I had a different version of an app, and I just needed to quickly grab the .env file. It would save a lot of time, to be able to view those files, without having to sift through backups and files.