Cloudron Forum

Highly appreciated 🙏

@LoudLemur I use cryptomator to encrypt sensitive files that I have on my nextcloud. Your use case is a bit trickier as you have multiple people working on the same file simultaneously. Take a look at the existing apps in the App Store like collabora, onlyoffice, and cryptpad. Cryptpad might be your best option though as it’s end to end encrypted.

Edit: There’s also baserow and noco. I’m not sure if the databases are encrypted.

@girish the example command did the trick! I was not using the correct syntax but also I didn't specify the database name. Once I did that I was able to reach the Ghost mysql database from the Discourse app 🙂

@girish said in Database Access & Backups?:

@sarah-white Good, was just checking since your comment got flagged as spam by the forum.

Sounds much like replies produced by asking ChatGPT to me!

@ei8fdb

I delete the dump file, then decide to backup from that's date - restore will fail?

No, a copy a the postgresql file is in the backup. The file at /home/yellowtent/platformdata/<appid>/postgresqldump is a temporary file. When we want to backup an app, we create a dump from postgresql and save it to that file. Then we upload that file to wherever the backup is located . After the backup is done, that file has no real use but we just keep it around because in some rare cases where you don't have backups it can help in recovery.

So, to summarize:

Safe to delete /home/yellowtent/appsdata/app-container-id/postgresqldump . But this will be created as part of the backup process, so it's going to be a pain. You have to delete this file everyday. Your final backup location will have a copy of the above file. Under <timestamp>/appid/postgresqldump . This is your backup, don't delete this file!

Adding my two cents in here for anyone who comes along. You can also access the DB using desktop software like Sequel Ace and it's incredibly efficient to me.

@murgero (you probably know this but just writing it out for the wider audience)...

Cloudron was primarily made to install and manage pre-packaged apps. This meant that addons were defined by the package and we don't want end users to make difficult decisions as to what database to use and what caching backend to use. Lesser choices cover 90% of the use cases.

But over time, we saw a lot of demand about custom apps. And thus LAMP app and even allowing custom packages. And now we probably also need dynamic addons (ie. select which database post installation or just before installation). While this is doable, this moves Cloudron more and more into PaaS territory. My initial instinct is that it's fine to venture into this space and maybe cover 90% of the use cases but we have to think through it 🙂

This is possible but will increase complexity in deploys and maintenance. I have also noticed that MySQL changes things between patch releases a lot. Maybe because their release numbers don't follow semver .