Cloudron Forum

Thanks for the report, this is fixed for the next release.

@girish yeah, I understand there is nothing about Cloudron here - just wanted to check your experience / understanding here. Thanks for sharing!

Since this question seems to come up often, I wonder if we should just show the timezone in brackets everywhere in the UI. @nebulon ?

What is your use-case to restore the whole Cloudron from Cloudron itself? I can see if Cloudron and thus the dashboard is not working, a restore might be required, but then it cannot restore itself in such cases.

No, it was a one-time issue so far. I posted it more as a bug report. Version 7.7.2, by the way.

@matix131997 My freescout app is the one that crashed I think and it's around 1GB only. I have backups disabled for my Nextcloud because I'm pretty sure it would never finish the job within a reasonable time even if it didn't crash.

Hey @girish, @nebulon, thanks for coming back to me so quickly! Happy to report that the fix worked wonders, and the backup completed successfully. As for our setup, we set up the backup server a while ago now, my memories are not the freshest. But IIRC we are using OpenSSH Server for Windows Server. And from what I can see Windows shell uses mklink to create hard links. But I have never used it.

@girish said in WordPress app container stuck on updating from package version 3.7.2 to 3.7.3: This happens with apps which contains files that change their size when the backup is going on. ... Maybe you have some plugin that writes to somewhere periodically? Thank you @girish Great advice and just the clue we needed. We figured out what that was, stopped it and then we could take a WP backup manually; and then we were also able to update to the latest packaged WP version 3.8.0 Thank you once again; your prompt help is much appreciated You can mark this ticket as resolved; cheers!

@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.

@girish Hello, no the backup sometimes fails with this error but I don't have any more information. I suspect the bandwidth because I have several servers which backup at night to the same destinations even if the times are staggered, it can happen that the backups are in parallel.

@girish got it, thanks