Cloudron Forum

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

@d19dotca I also suspect it's a problem with the iDrive storage. Because the backup problem is not a regular one. If he writes to iDrive support please let me know.

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.

We finally got down to this issue. Problem was that particular instance had a lot of backups in the db and we only took the first 1k backups into account for purging. Fix is coming with next release. If you hit this issue, send us a mail to support@cloudron.io so we can apply a temporary fix.

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

@fbartels said in Backups and users: Cloudron treats user names as unique Yes, we used to uuid and then went and changed all the apps to use username so that migration from one Cloudron to another (or anywhere else) is easier. As long as the username exists on the other cloudron, user should be able to login.

@philkunz We use the term snapshot and backup interchangeably in the docs. They are one and the same. I guess snapshot is something you initiate as a user whereas backup is something the system (automatically) initiates. Ultimately, they are both capturing the state of the app and uploading to configured backup location. To answer the questions: yes, backup policy applies to snapshots correct, snapshots (which you click manually) is just in addition to backups (which are taken automatically). there is nothing special about snapshots, we don't differentiate them from the automatic backups. We take snapshots/backups at the per app level. This way you can roll back a single app independent of others. To see the backups/snapshots of an app, you go to Backup section of the app. There is also a system backup (in the Backups view). A system backup is the one which you configure the schedule policy for (we don't have per app backup schedule). The system backup is essentially taking the backup of each app + backup of mail server + backup of the platform (like user information, domains etc) . It "groups" all these separate backups together and this is what is shown in the Backups view. In that sense, the Backups view is showing the "full backups". With the full backups, you can restore/migrate Cloudron to another server (so, it will be exactly the same as the current server with all the apps/domains/data/users).

I also had an issue with a backup in place but not reflected on the backups list.

Thank you, @3246 @nebulon - Probably I will reduce it to two per day and see how it goes. @3246 - I didn't know about B2's rate limit.

@RazielKanos Cloudron does hourly increments, not in minutes, so you can backup the app once an hour at most with the current settings. What service can’t be recovered if you still have access to the email/phone/recovery codes?

Instead of no-op, I recommend atleast just backing up to the same server. Select Filesystem and put location as /var/backups (this is the default).

This is intentional and hardcoded https://git.cloudron.io/cloudron/box/-/blob/master/src/cron.js#L6 If there is nothing to clean, this is a very cheap internal database lookup only.