Cloudron Forum

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

good points, thanks, gonna switch to cifs then!

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

Any plans to make this Cloudron-easy? https://docs.storj.io/api-reference/s3-gateway Otherwise, it looks like their integration partner Filebase puts a markup on that: https://filebase.com

We have wasabi support coming up in the next release.

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

@marcusquinn Great summary! I've similarly found that ingress transaction costs are more than my monthly storage costs with rsync option and tar zip backups keep timing out. @girish Thanks for adding the additional advanced backup configuration in 5.5! I've tried increasing it for my backups and am excited to see if it helps.

As a first attempt, you could try to restart the box process with systemctl restart box Also maybe look at the system logs, in case there are any hints for errors.

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.

@malvim said in Backup Improvements: Restic Backend: @necrevistonnezr how have you been testing backups? I have a raspberry pi at home, set up with restic/rclone backups as well. Once in a while I mount one of the latest snapshots and check a bit randomly if things "look ok". I'd like to have a better system to check if backups are okay, so any pointers would be appreciated. https://restic.readthedocs.io/en/latest/045_working_with_repos.html#checking-integrity-and-consistency and, as I said, spot checks for files with restic-browser.

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

@d19dotca Thanks for the write up, I will repurpose it for some our docs. Another user had actually informed us about this and it's been working reliably for them. So, we already had added OVH storage in the backups UI for the next release. [image: 1588704852591-357c53be-e4aa-4bcc-8cac-b8d7d543e388-image-resized.png]

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

This software should be able to do this http://duplicity.nongnu.org/index.html

This would go well with a secondary backup facility for all things Cloudron doesn't currently back up, which is valuable, such as Volumes. Add a few protocols for this such as FTPS, SFTP, RCLONE, RSYNC, etc..