So is this then fixed by now with getting unbound back alive?

@pbischoff thanks, I have fixed the link.

@jdaviescoates indeed, and idiot guide for an already running cloudron/mastodon app would be nice.

Got deepl running with simpel guide, so hope that for adding s3 bucket this can be the same

@jdaviescoates said in Backing up multiple Cloudrons to the same backup destination?:

And just to be double clear, having different prefixs results in different paths, right?

yes!

@nebulon you were right.
With the new version 7.3 the restore worked immediately and now baserow is running again.
Thank you for the great support!

@girish Thanks, that works.

@girish perfect! Thank you so much! I really highly appreciate the effort! Thanks! I see it now!

@girish So after the upgrade to 7.2.2 the problem vanished. Closing the Ticket.
Thank you for the help!

@msbt We won't break it intentionally atleast.

@3246 yes, kind of like a torrent file where you can select priority per file/dir and which ones to skip.

not sure a pause is needed, but more like a pre-start selection.

I'm sure @staff can enumerate mail and other core services as required items but with flexible priority/order.

Not only that, but while we're pondering that manual selection process with manual clicks, the essential bits can already be restored and ready for the next prioritized components.

@girish This makes a ton of sense, although I'm not quite sure if I'm doing it right. Under what you linked to, the section should be under the Resources tab, although I think it's moved to the Storage tab (no problems with that, I just wanted to make sure I'm handling it correctly).

2dfb1d41-c351-4f45-8352-99a9505b43d2-image.png

99f01fc2-bf27-42bb-8de1-dc11eaff4e2b-image.png

The part that's a little confusing is how 'App Data' and Volumes tie together in storage (now it seems this may be resolved as you said, since your working on Volume updating at some point in the future).

Anyways, App Data says to mount an external EXT4 disk, which I assume is done with the 'Mounts' interface right below it. However, the mount says that you are mounting 'Volumes'.

The documentation says 'App Data' is backed up. However, the documentation also says that 'Volumes' are not backed up. So that does leave me a little perplexed as to whether the data will be backed up or not. I think according to your comment, that it will be backed up (because you did say it would no matter where it is on the server). But I just thought I'd check 🙂

In any case, thanks for your help, and hope you have an awesome rest of your week.

@mdreira It should clean them up.

@humptydumpty said in Backup Failed:
This is most likely to do with postgresql not having enough memory. Please go to Services and bump up the postgres memory.

For a start, the next version will require the user to add an encryption password if the backup config indicates that the backup is encrypted.

@luckow It seems the multipart copy is not succeeding. What is the backup provider (minio?) ? If minio, do you see any errors on the minio side? Do you know how big the data for that app is?

@opensourced
Hello!

Is it possible, that you describe your way of connecting Cloudron with Truenas?

I'm using Cloudron on a VPS. In addition, I'm using TrueNAS at home. I want to use TrueNAS as backup space for Cloudron. Like you, I was thinking about NFS.

I'm wondering, if this connection is transport encrypted. Which port have you set in your firewall or are you using VPN? What user information have you set in TrueNAS?

I have experimented with Syncthing, to send my backups to Truenas. This works mostly fine. However, after a few days, I'm getting problems with permissions.

Greetings

Eismer

@girish ah yes, that makes sense. And recent ones are being deleted, yes. Thanks again.

@jdaviescoates you should probably use the cifs provider, since then at least the error message would be more obvious when not mounted

@girish ah alright, was moving some LAMP 7.2 and 7.3 to 7.4., clone does not work in that scenario 😉

This should be fixed in the latest package.

I will probably have to update https://docs.cloudron.io/backups/#restore-cloudron with more information like @subven has written since it seems this is not very clear.

@vladimir Can you try this change https://git.cloudron.io/cloudron/box/-/commit/bedcd6fccf58830b316318699375bc1f582a5d7a ? The file on Cloudron is /home/yellowtent/box/src/storage/s3.js. Essentially change the timeout from 3000 * 1000 to 0. And also change maxRetries to 10. You don't need to restart anything after the change since the code changes are immediately picked up.

(See also https://forum.cloudron.io/topic/3680/backup-issues-with-minio)

For completion sake: https://docs.cloudron.io/backups/#restore-email

Adding to this: Maybe it's possible to implement a backup browser via the file browser, at least for the rsync format and even for encrypted backups?

@robi Right, so the issue may be on the storage side. Now that you mention it, my object storage is inaccessible… 😡

@lucidfox rsync + encryption has file path length limitations i.e if your app has a file which has long path (not just the file name, maybe it is some 10 folders deep) the backup will error. The limitations are documented here https://docs.cloudron.io/backups/#encryption .

@Robin opened a feature request here to improve this - https://forum.cloudron.io/topic/3057/consider-improvements-to-the-backup-experience-to-support-long-filenames-directory-names

@ei8fdb said in Why is my backup drive full?:

I've moved the backup directories from /var/backups/ to my external drive. If I want to restore from those backup directories, do I need the contents of the /var/backups/snapshot directory also?

The snapshot directory is not required for restoring. BUT it's required for the actual the backups to work (so think of it as a working directory for backups). It's important to not remove that directory when doing backups! Since, Cloudron will use hard links from the actual backups to the snapshot directory, it's not really taking up extra space.