@sponch it's possible to slow down but we have to know what the rate limit is. I cannot find anything in our docs about this. Do you have happen to be in touch with their support?
Hello @flexplore
Please post the output of cloudron-support --troubleshoot and make sure you are not affected by https://forum.cloudron.io/topic/15442/ubuntu-24.04-kernel-6.8.0-110-regression-affecting-cloudron
I was under impression I'm quite clear... I don't think the decision made by authors correct.
I'm forced to do the backup, even though there is no technical requirement for that. I'm forced to do the backup the way authors want, even though I have my remedies.
As a result, I've just found out one Cloudron instance seriously out of date with a Docker security vulnerability in it. Just because authors decided that I have to have a backup to have automatic backup - to have my systems up to date.
Not sure I follow that...
If the second contains the System backups it would include those of stopped apps, where a backup was made there (since otherwise the backup data simply wouldn't be there). But I agree this is not great to migrate. I guess for now you would have to start the app, make a full system backup on the scondary backup site and then stop the app again.
The code for retrieving backup data for integrity check depeneds on format and storage type. Memory consumption is hard to predict, so presumably S3 with some kind of data on that storage just gets it over the 400MB
Hello @anthony-tran
Maybe you can try to disable IPv6 and see if this resolves the issue.
If so, try to enable IPv6 again and see if the issue remains solved or appears again.
@jakomo-freshi Yes, mysql 8.4 will be part of next Cloudron release (9.2) . I just pushed the changes to our code base.
Any guidance on the planned upgrade path would be appreciated.
The database upgrade is all automatic.
@nebulon Thanks for this - I can confirm that this is an issue with the S3 endpoint and a faulty server app release not accepting upload and throwing HTTP/1.0 400 errors.
If I may: The error message about MD5/checksum from Cloudron throw me off for a bit, not directly pointing at a lack of communication with the remote server.
Reverting to an earlier release on the S3 endpoint fixed the issue.
@Teiluj yeah, I have noticed that too. We don't want to lock it too much either (app location, footer, usernames, group names, etc - lots of scope to put offensive things).
