Okay, I figured out what my problem was. I had some failed backups from yesterday, when I tried to get hardlinking working (and I also had a permission issue with the MySQL dump). As of such, I cleared the backup disk manually, and then triggered a backup cleanup in the Cloudron UI. Then I tried to back up again, however, I believe that Cloudron keeps an index of files it has already backed up to keep things speedy (which is nice). As of such, even though the other files no longer existed, it was only backing up the changes. To solve it, I just changed the backup method to a different method, and then changed it back again, which cleared the index. Thanks for all your help on this :).

@d19dotca said in Backup to ext4 disk mount, using rsync, fails on first full backup but succeeds in all future ones.: Setup a new public cloud instance at OVH Create a block storage disk and attach it to the public instance created in step 1 Format the block storage disk and mount it according to this article: https://docs.ovh.com/ca/en/public-cloud/create_and_configure_an_additional_disk_on_an_instance/#using-linux Install and restore Cloudron from old server via DigitalOcean Spaces latest Cloudron backup ID Once Cloudron is running off latest backup, change backup configuration to file system using rsync non-encrypted with hardlinks, then initiate the first backup to the new location. This is where it failed for me. Hey, I know this is quite old, but I just had this issue too (v7.4.3), and I think I know what the issue is. So the Backup type is 'Filesystem (Mountpoint). Cloudron tries to hardlink between one device (primary boot, or one particular mountpoint) and the other (another mountpoint). Hardlinking isn't supported between devices sometimes though, so the hardlink fails. This issue seems to occur even with encryption though. Just a heads up in case anybody runs into this issue. Solution in the main time is to just not use hardlinks.

@girish I am just finding this thread. I would suggest adding these options: { name: '7 daily, 4 weekly, 3 monthly', value: { keepDaily: 7, keepWeekly: 4, keepMonthly: 3 }}, { name: '7 daily, 4 weekly, 6 monthly', value: { keepDaily: 7, keepWeekly: 4, keepMonthly: 6 }}, The first option is a common backup cycle (I think) and the second option allows for 3 more months of retention (and is halfway between the first and the current 12 month option).

This then means, that the system is using cgroups v2 now. I have updated the main docs section at https://docs.cloudron.io/packaging/cheat-sheet/#memory-limit for a start to make an app compatible with cgroup v1 and v2 (I guess in your case its sufficient to only support v2 now.)

Thanks ! It's working !

@andreasdueren i think I just followed their documentation: https://goauthentik.io/docs/providers/ldap/generic_setup

Hey all, reinstalled and then did a restore to fix things. Had a few trouble with restore, but was able to work them out. Also wrote a quick rsync command to take the emails from lost+found and restore them to their proper directories, so no emails lost :).

@saikarthik no worries

Sweet and thanks, I figured as much :). I'll have to check out the partition table change. Thanks so much for your help on this.

@nebulon said in Is it safe to upgrade my Cloudron?: It is a suboptimal behavior of the updater to show this flag for all updates as soon as we put a testing release out. Aha!

We had quite a few similar issues with namecheap in the last week on support. Check if your domain really only has no other DNS records reported via host <yourdomain> if there are multiple records reported, you have to ask namecheap support about this.

Thank you, Girish, for diagnosing and solving this bug so quickly! Backups are working again. If somebody else has this issue and needs to do the patch, you would go to the operating system for your server and find the file there and edit it. Cloudron also have a support tool inside Cloudron which enables you to temporarily grant ssh access to your server, which would let Cloudron's brilliant team patch it for you.

Please follow this thread at https://forum.cloudron.io/topic/10266/backups-are-failing

What‘s your browser? Is there an Adblocker (via DNS or VPN)?

Looks like you are using node 12, you need node 18. The security warning can be ignored . They are mostly useless. Automatic security alerts gone wrong.

@nebulon you're right. Here are the contents of the last file in this directory: 2023-10-24T03:43:21 ==> installer: Updating from 7.4.3 to 7.5.2 2023-10-24T03:43:21 ==> installer: This Cloudron version requires atleast Ubuntu 20.04. Please upgrade following https://docs.cloudron.io/guides/upgrade-ubuntu-20/ /home/yellowtent/platformdata/logs/updater/cloudron-updater-2023-10-24_03-43-21.log (END) I've disabled automatic updates. And I'm quickly going to upgrade to Ubuntu 20.04.

This is strange if nothing else happens, the code running there is https://git.cloudron.io/cloudron/box/-/blob/master/scripts/installer.sh?ref_type=heads#L126 so its not doing much but downloading nodejs and some extra filesystem things. Can you curl or curl -sL https://nodejs.org/dist/v18.16.0/node-v18.16.0-linux-x64.tar.gz ?

@privsec said in Cloudron Backups Bug: Doesnt Cloudron remove the backups that are no longer visible on the cloudron dashboard? I'm not sure what makes a backup visible there or not tbh. All my backups are displayed, I think. @privsec said in Cloudron Backups Bug: Whats the purpose of Cleanup backups button in cloudron? I think it just gets rid of backups that fall out of the retention policy. Have a read of the docs https://docs.cloudron.io/backups/#cleanup-backups As it says there, it runs every night anyway. But if you e.g. change your retention policy to 1 week and hit the Cleanup backups button then I guess loads of your backups stored in IDrive would presumably be removed (all those that are older than a week ago, aside from some special cases, e.g. previous versions of apps are kept for 3 weeks in case a update broke something but it took a while to realise) The real question is why I have you chosen the 1 month retention policy if you don't want to keep 1 month's worth of backups?

@81ewlska you can send a mail like this: Get mail server container IP - docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mail Get relay auth token - docker inspect -f '{{range $index, $value := .Config.Env}}{{if eq (index (split $value "=") 0) "CLOUDRON_RELAY_TOKEN" }}{{range $i, $part := (split $value "=")}}{{if gt $i 1}}{{print "="}}{{end}}{{if gt $i 0}}{{print $part}}{{end}}{{end}}{{end}}{{end}}' mail . Don't ask me how this works, I stole it from Stack overflow But essentially, CLOUDRON_RELAY_TOKEN is an environment variable in the container. You can also get this from docker inspect mail | grep CLOUDRON_RELAY_TOKEN and do some string manipulation. Then, send mail (example.com below is your primary domain): swaks --server <mail_server_ip> --port 2525 --from no-reply@example.com --to test@cloudron.io \ --body "Test mail from Cloudron" \ --auth-user no-reply@example.com --auth-password <relay_token> Note: above only works from the server itself. You cannot send mails from outside the server using a token.

Cheers, yes I've added the r8125 module to that now. I'll see what happens next time I need to restart. I haven't had to either, must be my cheap hardware choices biting me in the ass.