Cloudron Forum

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

@charlesnw I think the best approach is to do a restore yourself to understand how it all works . See https://docs.cloudron.io/backups/#restore-cloudron . For backup frequency, see https://docs.cloudron.io/backups/#schedule To overall explain backups: Cloudron Backup = Box backup + Email backup + App backups The box backup has many things including users, domains, profiles, settings, apps installed, backup i.e everything you do in the dashboard . Email backup is the emails (just that) . App backups is each app backed up separately. Together, all these backups form a single Cloudron backup. We are yet to hit a situation to restore user database separately. Not sure why this is needed but you can restore the full cloudron from Cloudron backup if your server hard disk crashes . You can also restore individual apps. This is needed often when an app update went wrong. There is no UI to restore an individual email account. Not sure why this is needed (can someone even delete all their emails by "accident" ?) But you can just copy that single mailbox from the email backup into the live cloudron instance to restore. There is no magic here, you can just open the backups and see what's inside them.

@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

@shrey there's some cases where the backup code forgets about older backups. For example, if you switch backup providers (even temporarily). We are trying to improve the whole situation in 9.0 . For a start, with multiple providers, we can track/cleanup more accurately. BTW, if you paste the filename of the backup in your Eventlog, does it find it there? I will look into making this more clearer i.e what is getting deleted and why not getting deleted.

@luckow give postgresql more memory

If the system runs out of disk space, a lot of side-effects can happen, so this could very well be the root cause then.

@simon said in Since v8.2.3: "Backup failed: Too many executable files.": As an idea: wouldn't it perhaps make sense to check this independently of the backups? Yeah, I think it's possible. Right now, we haven't focused on it because we have to then give feedback to the user in different ways when multiple apps fails but some succeed etc.

Can you explain better what is the error and what is the current situation ?

The number are just some pragmatic values. Empty dirs - 50000 , executables - 20000 and symlinks - 20000 . If it exceeds these, it will error.

This is currently not possible and not really planned either so far. Maybe you can use the mountpoint backup location on your system as storing backups on the main disk isn't a good idea in the long run anyways https://docs.cloudron.io/backups/#filesystem-mountpoint

Thank you! I'm working through the platform updates now. I didn't realize it was so out of date, as I had automatic updates turned on. Discovered that the same issue causing my backups to fail was also preventing the platform updates from completing. Manually stopping the Snipe-IT app allowed the updates to complete successfully, so I'm assuming this will be resolved, but will follow up here if not. Really appreciate the assistance.

Right, yes, that would make sense!