Cloudron Forum

@ccfu This is a very good news... I'm glad that you're not having any problem... I think Hetzner is one of best provider worldwide, but about S3 and Storage boxes they have still to improve their service... I'm also glad that Exoscale met your pricing needs...

Hello @CaeruleusAqua Please assist me in understanding this issue better. I want to figure out if is just a single filename or path and filename causing this issue. For this please go into the web terminal of your nextcloud and go into your /app/data/ folder. cd /app/data/ Please run the following command. It will find the deepest path and the longest filename. With these details I can further debug this issue. find . -type d | awk -F/ '{if(NF>max){max=NF; path=$0}} END{print "Max depth:", max-1, "Path:", path}'; \ find . -type f | awk -F/ '{if(length($NF)>max){max=length($NF); file=$0}} END{print "Longest filename length:", max, "File:", file}' Also can you please provide details about your backup provider?

I had the same 400 error with IONOS S3 and it turned out to be a simple setup issue. In Cloudron’s backup settings, make sure you select the IONOS (Profitbricks) option instead of the generic S3 choice. Then double-check that the endpoint and region match your bucket exactly—for example s3.<your-region>.ionoscloud.com—and that path-style URLs are enabled. After I corrected those settings, the backups ran without any errors. If you still get the 400 after that, try a small manual backup or upload a tiny file with the same keys using the AWS CLI to confirm the credentials. If the problem persists, sharing the few log lines just before the crash will help others spot what’s wrong. Hope this helps get your backups running smoothly.

yes @james I have also thought of using that. but manually running it on all mailboxes sounds like a pain I don't want to go through. I guess the current way I envision it is writing a script for imapsync that uses the api of cloudron to get all mailboxes and impersonates the users of the mailboxes to auto run imapsync on them. but then again maybe a block of the port is the way to go, so I don't have to write that script. the whole backup and recover process should be done quite quickly anyways. I am wondering though if this is not something others have gone through as well?

@nebulon said in Wekan backup errors blocking my Cloudron backups from completing.: This indicates, that the mongodb instance/service could not finish creating the database dump for wekan. It's odd because if I run a backup from the app it completes in a few seconds. There is very little data to backup. @nebulon said in Wekan backup errors blocking my Cloudron backups from completing.: Maybe it ran out of memory Unlikely given it's got over 4GB and I don't think I've ever seen it hit 10% usage. @nebulon said in Wekan backup errors blocking my Cloudron backups from completing.: Do you see any crash or more info in the actual mongodb service logs? I think I've looked and not seen anything obvious but I'll look again... Did you look at the logs I shared previously? said in Wekan backup errors blocking my Cloudron backups from completing.: Here are some logs: https://paste.uniteddiversity.coop/?7aed63d3ef7af3ba#BiicSooyTEjs2oEY1xQoGtizyB2Lwk7C6UWgCoBZJKjP Perhaps it could be something to do with this: vm.max_map_count is too low currentValue: 65530, recommendedMinimum: 1677720

Backups can only be configured by the superadmin/owner (the first user you created) . Looks like you are the admin

@makemrproper yeah, and actually it seems I might've been right afterall! I was sure I'd read something about the size... so I just search that thread for size and it is indeed there: Backup integrity - store size and checksum of backups. If they've got the size stored then should be easy to display it somewhere too!

Thanks for the prompt response, I got it sorted by creating a new bucket actually.

We discussed this problem here, I had this problem just few days ago: https://forum.cloudron.io/topic/12632/tarextract-pipeline-error-invalid-tar-header/

@nebulon I appreciate your advice. The backup server is not on the same location as the cloudron server. It isn't even on the same country (like I do with all my backups). Maybe I wasn't clear: the server has an OS disk (nvme) and a HDD for backups. The mount I showed is the HDD disk mount. It was just to check if any filesystem mount options were needed to improve performance. Thank you all.

Thanks to everyone for the responses. I fully understand the backups now and have reported to my board that it's indeed production ready for our organization.

@nebulon Thank you so much. Very helpful and quick.

@jpavlovski I confirm I had again three days ago

Using tgz instead of rsync did let the backup run normally, at least once right now. Let's call this a workaround for now, I'll see if this works regularly.

Looks like Cloudflare is interfering here and changing the data in transit? You would have to contact Cloudflare about this, but I have no high hopes that this would get anywhere.

@svtx life of a teenager

Where are you storing your backups?

For the first one, I guess you are suggesting a real rsync between the existing files and the remote. I think the issue is that rsync itself relies on a remote rsync service. Cloudron's rsync is strictly speaking not rsync, more like "individual files are synced as opposed to tarball". Even with sshfs, one cannot know for sure if there is a remote rsync service running. The second one looks like it can be fixed . I will should split this post though

check the forum on how folks did it with Google drive and the rclone config