Backup fails about 50-60% of the time
-
@bazinga do you have IPV6 running on that server ? ( after I turn it off backup worked ok after that )
-
@bazinga turning off ipv6 should be safe. Do this at interface level instead of server level. See https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux . That said, I am not sure how it helps here though...
Even though I'm not sure what database this refers to.
The Cloudron 'box' code connects to the local MySQL database. It is losing the connection and/or getting that error from the database in the logs. It's not clear why. Can you also check /var/log/mysql/error.log maybe ?
-
@bazinga turning off ipv6 should be safe. Do this at interface level instead of server level. See https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux . That said, I am not sure how it helps here though...
Even though I'm not sure what database this refers to.
The Cloudron 'box' code connects to the local MySQL database. It is losing the connection and/or getting that error from the database in the logs. It's not clear why. Can you also check /var/log/mysql/error.log maybe ?
@joseph I cannot even fathom how switching off IPv6 would help with this issue, but since you're saying that backup task uses MySQL db and connects to it - who knows, maybe IPv6 might have some effect there.
I've checked logs for mysql. There are few of them there zipped and they all are 0 bytes / empty, even on the days when backup task fails.
Backup keeps failing - in the past 4 days it succeeded only once. This is getting really annoying as not having backups for DR is a problem.
-
S SansGuidon referenced this topic on
-
@joseph I cannot even fathom how switching off IPv6 would help with this issue, but since you're saying that backup task uses MySQL db and connects to it - who knows, maybe IPv6 might have some effect there.
I've checked logs for mysql. There are few of them there zipped and they all are 0 bytes / empty, even on the days when backup task fails.
Backup keeps failing - in the past 4 days it succeeded only once. This is getting really annoying as not having backups for DR is a problem.
-
@joseph I cannot even fathom how switching off IPv6 would help with this issue, but since you're saying that backup task uses MySQL db and connects to it - who knows, maybe IPv6 might have some effect there.
I've checked logs for mysql. There are few of them there zipped and they all are 0 bytes / empty, even on the days when backup task fails.
Backup keeps failing - in the past 4 days it succeeded only once. This is getting really annoying as not having backups for DR is a problem.
@bazinga I had similar issues in recent days using Contabo Object Storage on a Contabo VPS.
I ended up fixing it all simply switching to a different storage solution, here Hetzner Storage Box through SSHFS, and that solved most of my pains.
If you can, try that and save yourself some time and suffering. -
After some time, Girish has added extra code that would increase re-tries count and timeouts, so eventually B2 started working, more or less.
With this said, I've just switched over to Hetzner and will see how that will work for me. Don't feel like paying money to B2 if their backend is overloaded and constantly results in various issues.
-
The multi-part copy was just hanging. If someone hits the same issue, you can just apply this one liner https://git.cloudron.io/platform/box/-/commit/b4d58f0609b1c252fa44799eccbbd9c691c7c2ac . The file is /home/yellowtent/box/src/storage/s3.js
-
G girish has marked this topic as solved on
