Cloudron Forum

Sure, I'll write you there.

@daixiwen Even better, they HAVE already allowed for specific backup persistence: [image: 1745912539127-704862fe-911a-4719-960b-94f162df1e64-image.png] I'm going to go try that out. The wording definitely makes it sound like at least one backup, "the latest backup", should be available, but my point still stands. As perfect as Cloudron is, I've bumped into hiccups with backups myself, too. And so I pay close attention to them. In the situation you mentioned, you can either let your stopped app backups keep disappearing while you wait for a solution, or you can realize it needs a bit of your help. EDIT: I see you wrote " I'll now try having at least one manual backup set up as persistent and see in two says if it's still there, but ideally this should occur automatically." so good on you for taking it into your own hands. Let us know what happens!

I have updated the screenshot

Again: https://forum.cloudron.io/post/79353

@dylightful there is a bug when setting up Linode Object Storage (it's already fixed in next release). For now, you have to choose S3 compatibly Storage in the Storage provider combo box and input the values. It's the same thing internally, the Linode Object Storage is merely a convenience that fills out some fields like the endpoints.

This is fixed in master as well now.

Yeah, thanks. I thought thats posible, but i will do it like our adivise

Closed due to inactivity

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.

To answer the original question: I think root user is the first/admin user that you signed up with Wasabi. If you create users after that, they are called sub-users. Depending on your setup, you have to create a key for the root user or sub user. I guess you can just create the key for root user if you are not using sub-users. See https://docs.wasabi.com/docs/creating-a-user-account-and-access-key

Might not be limited to „lock“ files: Today I had a similar error (first time ever!) du error: Command failed: du -Dsb "/home/yellowtent/boxdata/mail" du: cannot access '/home/yellowtent/boxdata/mail/vmail/[REDACTED]/mail/dovecot.list.index.log.2': No such file or directory

@jayonrails https://forum.cloudron.io/post/47122

aw. well, it told me witch post, but it didn't say witch post in particular in this particular topic. unless you can upvote the topic itself

@robi said in Backup failed: ENOENT: no such file or directory, open '/mnt/cloudronbackup/my.uniteddiversity.coop-netcup/snapshot/app_08388b1d-12c7-42c2-b6bd-a5c5be5cfcbb.tar.gz': It's odd that backups ran fine until they didn't with that same default all this time. What would make backups use more memory over time? It would be interesting to know a little more about that, indeed.

Hello @shrey This is expected. Each Cloudron release and update has to treat every system the same and can not respect changes made by the user. Changes made to the core services need to be managed by the user manually.

@Neluser It's always appreciated when solutions are posted because eventually someone has a similar or same question. Thank you!

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

A server snapshot is useful to recover quickly. But a backup is quite separate : Backups are generally separate from your server provider. If you lose access to AWS (maybe they think you are a bad actor or a billing failure makes them kill everything, this happened to me), then backups are a way for you to recover. Snapshots are almost always in the same server provider. Backups are portable . You can't take a EBS snapshot and put it in Digitalocean On Cloudron, backups are per app. So, you can restore each app individually unlike a server snapshot which will roll back everything. Backups help in upgrading things. For example, you can upgrade/migrate database using backup of old version into new version. So, they have different use cases. Both are useful. Use both when possible.

Most of the time the scheduled backups now succeed, but not always. I'll keep an eye on the backups and make manual backups if the scheduled failed. Let's see if the changes of scaleway improve the situation. Thanks again for the suggestions and help.