Cloudron Forum

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

It was happening across multiple servers at the same time yesterday. Looks to be resolved now.

The issue is now resolved. The problem was with the GitLab database, where we found 160 GB of logs. The database dump was failing because there wasn’t enough free disk space. We have purged the database, and backups are now successful. Thank you for your support.

Update: cloudron-support --troubleshoot returns: [WARN] netplan configuration is empty. this might be OK depending on your networking setup [FAIL] DNS is not resolving Further, /etc/netplan/ is empty. How do I generate the correct .yaml file to include there? Final Update: I was able to crate a netplan .yaml file by following these instructions.

I would say lets close this here. I do not see any failed cleanup jobs even multiple jobs try todo the same.

Restic: https://restic.net Supported repos out of the box: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html Other repos when combining restic with rclone: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html#other-services-via-rclone A starting point: https://docs.cloudron.io/guides/community/restic-rclone/

I'm thinking about the possibility that the length of the encrypted filenames might be too much for Wasabi... I'll dig deeper...