Cloudron Forum

@girish No, I upgraded directly to 9.0.5 from the 8-series and never set up multiple backup sites.

zfs is on the host. cloudron uses non-cow inside the vm.

Cloudron 9 has pretty much the same flow here. Maybe we have to revisit what the main app cloning use-case is, to figure out a better flow there.

This should be fixed in Cloudron 9, where a backup failure notification email can be configured per user.

I have updated https://docs.cloudron.io/backups/#restore-cloudron and https://docs.cloudron.io/guides/download-backups/#backup-file-names . Bit of a hasty edit but time is really right these days!

Awesome. Many thanks. And this is not a goodbye, I have a lot of other apps here, and planning to work on more

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

@CaeruleusAqua which S3 provider are you using?

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