Cloudron Forum

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

OK just to recap - This seems to be working on my test system. This is after I followed the steps for my VPS to add a disk and the Cloudron instructions to add a disk and a volume. I did this as root. I used the "disk" in place of "volume".

Stop the app

mv /home/yellowtent/appsdata/dfaa72b8-8c42-433e-a001-c9d58563379b /mnt/disk/matomo/ ln -s /mnt/disk/matomo/dfaa72b8-8c42-433e-a001-c9d58563379b /home/yellowtent/appsdata/dfaa72b8-8c42-433e-a001-c9d58563379b chown -R yellowtent /mnt/disk/matomo/

Start the app
This would be nice to automatically happen with a Cloudron tool.
I will post back and edit if I find any issues when doing this on the production.
Thanks for all of the help.

@SebGG this is normal behavior starting from 8.2 . we put this check in place to prevent backup or app data corruption .

Too many empty folders. This means that something suspect is going on with the app . When you create too many empty dirs, you run out of inodes over time and this leads to fs corruption. Since empty dirs don't show up in du listings, people wonder why fs is becoming fullish when files are not taking space

Too many executables. This is a security issue if data files are executable. In most cases, this is because user used a tarball which had incorrect permissions inside it . Or the mount permissions or wrong.

So, the backup failure is a way for end users to check on both the things above.

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

There is currently no generic way to do this from Cloudron side. Depending on your backup storage you are using, you probably can download directly from there.

It looks like the problem is indeed gone with 8.1
Thank you!

This was resolved via support. For some reason unbound was not running. Restarting that made the backup storage work again (we may have a wrong configuration, where unbound is a systemd dependency for the storage mount, which seems like not needed anymore)

You should be able to download the whole task logs from the logviewer, which should give you more context which app was currently backed up.

@Usman said in Cloudron Backups to BackBlaze And RC Backup:

Right now, a 2 GB app backup is causing 4GB storage. (one 2 gb file in snapshot and one 2gb file in Date directory.

Yes, this is the case. But also, the system is optimized for having many backups. If you have 30 full backups, this is just 62GB. The 2GB is negligible in this context.

There is no "backup" options in RocketChat itself. The only option I have configured is Backups in cloudron. So this is done by Cloudron Backup procedure.

I don't see this in our Rocket.chat backup atleast. There is no second mongodb dump.

Top level:
c0d501f9-d319-41af-bb24-edca5ad89810-image.png

Inside data:

d25f6c57-a23e-4c0d-b667-589b68a1d9ab-image.png

@cocam123 whoops, you are right! I forgot there is an option in the UI for this 🙂

The exact checkbox text is Remote file system supports chown