Cloudron Forum

@nebulon Thank you for your response. Yes, it seems the issue is indeed with hardlinks. I have them enabled. I will try to wait for the Cloudron update, or I might consider using Borg for backups to the Storage Box. That should probably resolve the issue. Another option is using rsync with the -H switch, but I haven't tested it yet. Thank you very much for your help.

@dsp76 thanks, will adjust the code accordingly. https://docs.ionos.com/cloud/managed-services/s3-object-storage/endpoints says it is a "contract owned" endpoint and it's the future

@ekevu123 said in Backup settings: which blogs installing and updating other apps, and sometimes I need that A fix for this is coming. Backup had a global lock which is being removed. As for the bigger question, there is no clear answer. Backups take time, it is supposed to be something in the background and taking less resources. Not something actively monitored. Even in AWS and DO where they have complete control of their servers, if you take a snapshot of a 100GB machine, it takes a LONG time - they suggest 1 to 3 minutes per GB . It just the way it is. (240GB is worst case 720 mins or 12 hours where they have complete control of disk and server).

@ekevu123 there are other posts suggesting more options in performing backups. Might be worth doing a search. This sounds a duplicate. Doesn’t mean it’s not worthwhile. Just clarifying.

@philkunz said in No support for simply uploading a backup through the web ui?: Ok got it. Is there a particular reason, why a simple upload through the webui is not supported? In some ways, this can be considered a security issue. If we had some bug in Cloudron code, then one can import/delete your existing data in the app. This is also why we don't allow deleting backups via the web ui. But (atleast I) have come around to this a bit. Maybe this can be considered a usability issue. We just need to figure out some safety hatch when user uploading a backup (maybe require 2fa, reenter password etc).

Unfortunately, we ended up breaking https://forum.cloudron.io/topic/11993/backuptask-crashing-after-8-0-update . But yeah, overall the fix is good.

The issue here had to do with something in JupyterHub container creating a massive number of folders recursively. Think 300k folders or something. Nuking all that stuff, made backups work again.

This is not possible, no. The structure of data of both the apps are quite different. Also, when you backup Cloudron apps, the code is not part of the backup. LAMP app is sort of a special case here since the code is part of the "data" and part of backup . You should be able to migrate it manually though. Import database and copy over the needed files.

Well, I thought you would say that. But how about at least make some suitable limits? E.g. the memory limit shouldn't be higher than what I can afford based on my usage. Also, if I can only upload up to three parts simultaneously that require as much memory, why can the memory limit and the upload part size differ? Wouldn't it make more sense to have one setting for both?

@ChristopherMag Wow, what a great story, with a happy ending, too! Thank you for taking the time to tell us the tale.

Closed due to inactivity

@girish got it, thanks

@girish said in Bunny Storage for Backups: BTW, looks like they said S3 support is coming 2 years ago - https://bunny.net/blog/introducing-edge-storage-sftp-support-s3-next/ There is also a bit of an update here https://bunny.net/blog/whats-happening-with-s3-compatibility/

CR 9 (or earlier?) will have multi-backup destinations which might do what you're looking for without having to go thru a VPN and all that mess. But, have you seen the new VPN app? https://forum.cloudron.io/category/20/vpn

@girish Thank you very much !

@mic-testing-123 We have replied from there asking for more info. (specifically the backup backend and the backup logs).

@DualOSWinWiz yes, correct. This looks like some kernel related issue or some missing ubuntu package. Can you try to make the NFS mounting work with just the CLI . This will remove Cloudron out of the equation. I think it is possible some missing package or miscompiled kernel.

I can now say safely that the backuptask crashes while working with Immich. Maybe I should choose different setting? I switched to Backblaze recently and I am currently using rsync. Maybe there is a way to do this more efficiently considering that there are so many files to upload? I was assuming rsync might be more efficient than a tarball because it only syncs the changes, but I might be wrong?

Closed due to inactivity Note: A lot has changed for backups and will change even further with Cloudron 9. If this issue persists please reopen this as a new issue.

@TheMoodBoardz Does it fail with tgz format also? Not sure how to debug this since it is just crashing with no real logs. If you reach out at support@cloudron.io , we can debug further.