@smilebasti Possibly because the destination file system does not support hard links. In the Backup -> Configure, there is a checkbox to disable hard links.

Thanks, I have added both to 4.5 roadmap

To know the backup scope, you can sum up all the apps listed there + email data + box data. Then you would have to multiple that by the number of backups which are stored (eg. once every day for 1 week or so) This would be the maximum of storage required using the tarball method. For rsync, it would be much less since it would do incremental backups.

@jdaviescoates said in Who else is hosting their Cloudron server on Hetzner Cloud? How best to do backups on Hetzner?: use a Volume instead! it's often the option I choose

@girish yep. minio backend

@timmeh Your assessment is correct. If you switched the backups to rsync mode, you can remove the .tar.gz files. They are left overs from your previous backup. Maybe we can add an option to remove the old backup files (of previous configs). But of course, that will require cloudron to remember previous config as well. Also, to be 100% clear, only remove the .tar.gz files. Do not remove any other files in the snapshot directory. The snapshot directory is the "working directory" of the backup system and stores the previous state.

We investigated this offline. The root cause was that the S3 storage service (strato hidrive) does not support multi-part copy. The workaround is to use the rsync format (Backups -> configure -> Format) when you have backups > 5GB.

@girish Oh okay, thank you! My next question was going to be about deleting the snapshot folder, but it was already answered. I appreciate it!

I was unaware of the incremental feature in rsync. That will work for me, thank you!

@njha The Cloudron version of minio is intended for hosting static file assets and not as a backup destination for Cloudron itself. If you want to backup Cloudron to minio, we recommend setting up a separate non-Cloudron server that just runs minio that proxies to b2.

@tadeas I guess you are referring to https://github.com/storj/storj/wiki/S3-Gateway ? You can already use an arbitrary S3 gateway btw in the Backups view dropdown. Once it reaches production, we can add it to the Backup providers dropdown as a proper option.

We have wasabi support coming up in the next release.

https://git.cloudron.io/cloudron/box/issues/654

Would love to see this.

Can you check if the backup format is correct (i.e tgz or rsync) when you restore from the backups? The logs are in journalctl -u box -a.

Thank you @girish for the refund! Much, much appreciated!

@nebulon Yes I know but I think it's a kind of "dirty intregation" regarding how much you have implemented Amazon/DigitalOcean S3 ... And I'm probably not the only one that need a backup in French Infrastructures. @girish Hum, So bad because it's totally functionnal for me ... I don't know if there is some limitations for others countries.

@girish thanks for the info and extra-feature, that's good to know and might come in handy! I'll also tell people not to use that long filenames to avoid such errors.

Maybe we could at least introduce an optimization of the databases from time to time. The size of the referenced "ttrss_entries" table went from an insane 1,238 MB (!) to 583 MB after optimization. The following command, maybe via a button, should to the trick: mysqlcheck -Aos --user=${MYSQL_USERNAME} --password=${MYSQL_PASSWORD} --host=${MYSQL_HOST};

@girish I also realized that the mysqldump for the TT-RSS app is huge (679 MB in my case). Could you implement some compession in the database dumps (and use PostgreSQL as recommended by the author)?