Cloudron Forum

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

Please follow the thread at https://forum.cloudron.io/topic/9333/hetzner-storage-box-cifs . Just trying to keep all this CIFS related stuff in one place.

A little update on this: I help a friend migrating their cloudron to another server and set-up a new backup storage (also using a Hetzner storage box). Server migration worked fine (that was not using the Hetzner box). When it came to connect the new storage box we faced issues. We generated 4 pairs of ssh keys: rsa with paraphrase ed25519 with paraphrase rsa without paraphrase ed25519 without paraphrase With all four we could connect to the storage box from outside cloudron (using terminal or from file manager). 1. and 2. required the paraphrase to do so. On Cloudron: and 2. didn't work >> expected as paraphrased is required worked just fine if trying to connect to the box by created a new volume or a new backup storage the connection failed as reported above in this thread. BUT if the volume or backup storage was already present and mounted (using key 3.), then I could go to the settings and replace key 3. by key 4. and then it connected fine. Maybe this description might help tract where the issue comes from, since it only happens when mounted a new valume/backup and not when it's already present

@TheNils If you write to us on support@cloudron, I can debug further. It's not clear what's going on.

@holm yes, thanks. This is planned but with a slightly different approach. The restore process will keep track of what it's downloaded, so that the download can be incremental. That way, one ideally doesn't need to select anything.

I checked and got this result. Indeed, with large file sizes, I had problems with backup. (Archive size less than 3 GB was transferred to the nextcloud without problems. With a larger one, an error almost always occurred when copying or restoring.) Thanks for the advice. I was really interested to see the result. The topic can be considered closed. Thanks to all.

@carlostph One thing is that what might be causing the upload to stall is the CPU (because of gzip). Can you also check tar cvf - /home/yellowtent/appsdata/<mastodon-app-id/ and pipe that to s3cmd ?

@affinity yes, so in coming releases, we will have a checksum to verify backups. Hopefully, this is caught sooner and not just when trying to restore.

@p44 This is a bug in the current release, which is already fixed. To workaround, put the backup somewhere in the filesystem and import using the Filesystem provider.

Closed due to inactivity Note: A lot has changed for backups, if the issue persists please open a new topic

@girish Your question got me wondering what was going on. Turns out, two apps on the volume both had caches that were insane (one due to an old uninstalled WP cache plugin that was removed, but maintained its 12 MILLION cached files, and the other was Mastodon, which needed some manual cleaning for the 800k files it had cached). Turns out there were just SO MANY folders/files that any attempt to backup or read the size would just time out. D'oh!

@doodlemania2 that's exactly what the change fixes! it won't let you save that invalid config anymore (i.e putting a bucket name in the endpoint)

@mononym said in Cleanup Backups failure: I guess the issue is in the settings then? Check Backups -> Schedule and Retention -> Configure