Cloudron Forum

Maybe search for "Hetzner" and "EACCES" - and thou shalt find....

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.

@imc67 yeah, the logs are probably not there anymore. One thing is if you go to the Eventlog section of the app, do you see if a backup was ever made?

I can confirm there is this quirk: If an app is stopped and backup was never created, then we don't have backups for this app. Maybe we have to inform the user about this somewhere.

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

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

Hi @girish
By when can we expect a (stable) solution for this?

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