Thanks for your replay. This is the third alternative. However, this is linked to a few cons: Skillgap regarding IPv6 I am using unifi hardware which has a pretty basic IPv6 implementation

@girish said in Issue with the API to change MemoryLimit: --data-raw '{"memoryLimit":973078528} Thanks! this bit helped.

Solved! Just for the sake of someone else stumbling into the same issue : Backup SSHFS mount with hetzner storage box should always be mounted pointing to the exact sub folder where backup will be stored, so the path would be /home/yourfolder and the URL to the server should not contain any path. Now, if you use the same storage volume mounted a second time, as a volume to be added to specific apps then the URL is always ID.your-storagebox.de and the path field is simply / no need to specify any folder. The issue here is that I had it to mount the URL of the storage box ID.your-storagebox.de/home + / in the path and that was the origin of the mess, the odd part is that it did mount and the volume was usable via the filemanager just fine, it's just that the hdparam.sh script would freak out due to this confusion in the path. Anyway, solved !

@robi Yes, I was expecting something like that.

Thank you, @3246 @nebulon - Probably I will reduce it to two per day and see how it goes. @3246 - I didn't know about B2's rate limit.

@philkunz We use the term snapshot and backup interchangeably in the docs. They are one and the same. I guess snapshot is something you initiate as a user whereas backup is something the system (automatically) initiates. Ultimately, they are both capturing the state of the app and uploading to configured backup location. To answer the questions: yes, backup policy applies to snapshots correct, snapshots (which you click manually) is just in addition to backups (which are taken automatically). there is nothing special about snapshots, we don't differentiate them from the automatic backups. We take snapshots/backups at the per app level. This way you can roll back a single app independent of others. To see the backups/snapshots of an app, you go to Backup section of the app. There is also a system backup (in the Backups view). A system backup is the one which you configure the schedule policy for (we don't have per app backup schedule). The system backup is essentially taking the backup of each app + backup of mail server + backup of the platform (like user information, domains etc) . It "groups" all these separate backups together and this is what is shown in the Backups view. In that sense, the Backups view is showing the "full backups". With the full backups, you can restore/migrate Cloudron to another server (so, it will be exactly the same as the current server with all the apps/domains/data/users).

@fbartels said in Backups and users: Cloudron treats user names as unique Yes, we used to uuid and then went and changed all the apps to use username so that migration from one Cloudron to another (or anywhere else) is easier. As long as the username exists on the other cloudron, user should be able to login.

@girish said in Share the same database: Currenly, you cannot create a database. The databases are precreated/destroyed by the platform. .. as Apps are installed and removed.

Ah I see, there is a stylesheet bug when a background image is used. Fixed with https://git.cloudron.io/cloudron/box/-/commit/ccb925be5d9c9280a34b2a6e506a02d211ca5e9f Anyone curious about the issue, if filter properties are applied, all child nodes will be put on the same plane and thus multiple z-index values for that node tree does not apply.

@imc67 thanks for reporting back!

@plains-digital yes, you can also restore app by app. https://docs.cloudron.io/backups/#import-app-backup . But obviously, restoring entire server via backup is far simpler.

Yes. They used to come nagging back. Maybe it's different this release. You can imagine what happens to mobile notifications. On a separate note, we did discuss having a button for "Upgrade all apps" in the UI. That button would be really helpful.

Thank you

Thank you @BrutalBirdie and @girish, I'll take a further look.

Nicely detailed docs here - https://www.axigen.com/documentation/axigen-auto-discovery-p49119962

All went well, apps are restored and all is running as intended

This continues in https://forum.cloudron.io/topic/9514/panic-mode-update-failed

ahhh, so just have to nix cloudflare altogether, thanks! confused myself because my plains.cloud is cloudflared, but mail.plains.cloud specifically is not! appreciate the clarification

Right, you need to figure why unbound is not starting. The logs are in journalctl -u unbound -fa . Note that if unbound doesn't work, DNS doesnt work properly on the server and makes this quite unstable (as you experienced already).

We can't change the doc page yet atleast until 7.5 is stable. Also, 18.04 is still supported to install pre-7.4 releases.