Cloudron Forum

@d19dotca I have added some docs now. https://cloudron.io/documentation/backups/#schedule has info on the timeout and nice. https://cloudron.io/documentation/backups/#concurrency-settings on the concurrency settings.

@rlp10 there is no clear cut between which backup target is preferred. We try to cover a few options to cover a range or use-cases, but all should work. If you own the backup machine, I would anyways not advise to encrypt backups. Unencrypted files on trusted storage is a lot easier to restore if worst case trouble hits

For tgz, what we found is that the slowness is mostly because of the gz part and most of the cloud VPS are not very fast at this. And the whole tgz by it's nature is single core. For rsync, parallelism and buffer size were indeed a constraint. But these are both now configurable in the 5.5 and 5.6. Note that the concurrency her also depends much on the storage backend. For example, DO can handle only 20 at a time. But S3 can handle 1000s at a time. One has to experiment with the values a bit to figure the right number. Mostly s3 connectors don't publish ideal sizes and concurrency unfortunately.

@girish that’s perfect, great detective work! Thanks Girish for working to solve that. I really appreciate it. I’ll keep an eye on it in my server you patched and see if the issue comes back. Thanks again!

@shan I will mark this thread as solved. Let's follow up at https://forum.cloudron.io/topic/7750/backup-uploads-time-out-after-12-hours-can-no-longer-manually-adjust-timeout-to-be-longer

@marcusquinn said in Cloudron Backups to GitLab/GitHub Private Repos: Not a high priority - but might be nice for both the really tight and multi-location/provider redundancy aims. I have to think through the rest but multi-location backups is in our radar. We have a long pending issue about this https://git.cloudron.io/cloudron/box/-/issues/528

@girish I don’t think I’ve tampered with anything there, no. Very good, as long as there’s some mechanism to reliably start over I’m happy to do that. Thanks! In the longer term maybe some kind of ”Start over” mechanism doing this same thing can be exposed to the backup page…

@nebulon Thanks, this was the reason for my problem. After I uncheck "mounted filesystem" Cloudron was updated to 5.4.1

@nebulon That did the trick, thanks a lot again.

Thank you everyone for the clear explanations as always.

@ultraviolet Glad I could help...

@girish Yes, it is, I switched 3. also to every 12 hours + 1 week, and also that one is backing up once a day. I'll ping you.

@girish wrote: Are you able to open a request [for this]? Done, thanks: https://forum.cloudron.io/topic/4306/provide-ui-support-for-choosing-app-package-version-during-installation

If you have a floating IP (in DigitalOcean lingo), elastic IP (AWS) or equivalent, you can make Cloudron use the floating IP (Network -> Interface -> Enter the floating IP). Then you can restore Cloudron to another server, and then when restoring is done, you can switch the floating IP to this new server.

@scooke said in App or Full backup fails with reference to 'layout'?: If it hangs again should I just email you directly with the logs? Yes!

Quick update: I just manually ran another system-wide backup and it was successful, so it seems it may have just been a one-off and probably won't happen again anytime soon, was likely just coincidental I was making a bunch of changes to it yesterday considering other system backups proceeded without issue since the time I made those changes. But I'd love to get a second-set of eyes for insight into if this is something I should fix to prevent it in the future or just a one-off type of thing that can safely be ignored.

@thibaud Are you able to generate credentials for me to test your minio instance? Maybe just create a test bucket for us. Just send them to support@cloudron.io. I just tried to setup backups to a minio installed on Cloudron and that works fine.

Usually, "Killed" means it ran out of memory when importing. Can you try to restore again and see "dmesg -w" output in parallel to see if that is indeed the case? You can bump the memory limit for the restore logic as indicate here - https://cloudron.io/documentation/troubleshooting/#backups

@girish They are unusual I would say, yes. It's a file that is being updated on a daily basis so it has a file history of 30 different versions in NextCloud. They are .db.crypt12 files, which is a database backup of WhatsApp about 120MB in size.

In my case it was a Redis service not being active, thanks!