Cloudron Forum

I don't think there is any backup option out there which can do what you are hoping can be done. The one exception is if you are manually extracting the data to be restored, and putting them in different locations. I just say this so you don't go feeling like this is some sort of weakness of Cloudron. Backups rely on timestamps and exact conditions. You couldn't restore the second backup because it would look for the time slot from which it was built, in the records, and those records aren't going to be in the currently restored backup. But if it is the media you want, then the fact you do have separate sets of backups does mean you can at least navigate through the backup and find that media, and then as @nebulon said, manually add them back to your Mastodon. But I gotta say, why do you need to have this media? I mean, Mastodon IS social media, and it's meant to be ephemeral. If there is some info you like, then screenshot it, or click the link and bookmark it, print it out to PDF, or follow the poster (to then check them out post-restore to see that specific post) etc. But saving it and keeping it to be viewable only within your Mastodon seems like a use even Mastodon wasn't really meant for. Anyway, good to hear you are back up and running. Hope the new year remains happier. I'm @shane@social.futurnumerique.com if you want to expand your follow/followers!

Sure, I'll write you there.

@daixiwen Even better, they HAVE already allowed for specific backup persistence: [image: 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.