Cloudron Forum

The multi-part copy was just hanging. If someone hits the same issue, you can just apply this one liner https://git.cloudron.io/platform/box/-/commit/b4d58f0609b1c252fa44799eccbbd9c691c7c2ac . The file is /home/yellowtent/box/src/storage/s3.js

@girish Ok, great! Thank you very much for the information. I really appreciate your time. Thanks again!

Wonderful. Thank you @Joseph, that change to the endpoint URL did the trick. The configuration saved successfully.

@Wenhardt try Scaleway - not perfect but works generally

@Beardmancer said in Failed backups and email config issue since 8.0.3 upgrade:

I decided to go ahead and try adding this to /etc/systemd/resolved.conf since it's easy enough to comment out.

DNS=8.8.8.8 1.1.1.1

After doing that and restarting the service with systemctl restart systemd-resolved, things seem to be working correctly. The file /etc/resolv.conf lists nameservers now and a manually-initiated backup just completed successfully. Thanks for the hlep @nebulon !

In the future, is there anything I should look out for to avoid this? I don't know what caused it. Maybe it was the 8.0.3 upgrade, or maybe it was an Ubuntu update? I think I rebooted Cloudron for the latter recently. If there's a configuration I might have setup wrong, I'd love to correct it.

It did turn out to be a DNC issue which Joseph at Clourdon support fixed and then created a backup.

@girish One thing to note, all stopped apps where not imported through the restore method even tho they had backups retained with them. We are still trying to find and recover those apps atm, but they must be buried in a random 2024-04-08-030000-684 folder. Never the less.

Is it possible to recover data from the snapshot folder? what is that for if backups pull from the other folders? I think our stopped apps are in there but Im not sure how to recover them through the front end that way.

One thing that would have made this process so much more seamless is just including that restore config file in the snapshot folder, and the corresponding configs for each app backup, would have saved us hours of finding the correct backup id manually for each method, since Im assuming they are slightly different?

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