Thanks, this was an oversight and indeed the task got never refreshed. This is fixed then with https://git.cloudron.io/platform/box/-/commit/6178538a4c4b712b426a8b11eeb6ae8ac5fe9f10
Hello @dualoswinwiz
Thanks for providing the output of the troubleshoot.
Your Cloudron version 9.2.0 is outdated.
The latest Cloudron version is 10.0.5, and we are moving towards Cloudron 10.1.
Since Cloudron 9.2.0 many improvements and fixes have been implemented regarding Passkeys.
Please update your Cloudron to the latest version so we ensure this is not just an outdated Cloudron issue.
@james Well, looking at the logs, it’s actually running fine. Even though the UI dashboard looks stuck at 5%, I managed to successfully update it to version 10.0.5
jdaviescoates said:
My guess is mail will be ok next time too
Yep, the most recent rsync back-up into the new folder (rather than the same folder as the rsync backups were going into before the server migration) worked fine too and now I have rsync backups that pass the integrity check - finally!
So it seems clear the issue was some file changes that happening during the full Cloudron server migration got rsync confused.
Hello @jayonrails
The only instruction was:
james said:
To fix this please run the following command from your ssh root/sudo session:
bash /home/yellowtent/box/setup/start.sh
But you also did run:
systemctl stop box
apt install mysql-server
systemctl start box
From the log it looks like everything worked out correctly.
Please make sure to carefully read provided instructions in the future since you did run commands that where not instruced to be executed.
Please also read https://forum.cloudron.io/post/129886 which explains that the binlogs might not be purged correctly and how to clean it up.
Otherwise some binlog files might remain and block some diskspace.
Hi @james - I also received a response today. Hope its the same group of people you talk to
I let the AI compare the responses:
Key differences between response I received and from your summary:
Root cause: GC overload vs. synchronous unlinking of old object data.
504: Both say the proxy times out after 600s while backend processing continues.
HEAD vs. GET: Response I received assumes processing may still be ongoing and no data loss; from your summary says the affected data is unrecoverable.
CopyObject / MPU: Covered as under investigation in response I received; not addressed in your summary.
Fix: General GC optimization vs. explicitly decoupling GC from CompleteMultipartUpload.
Anyway - looks like we helped uncovering the root cause
Thanks, that did it!
I increased total swap from 4 GiB to 8 GiB, leaving the backup task’s memory limit at 3 GiB and all other backup settings unchanged.
The next attempt completed the backup successfully, then updated Mastodon from package 1.19.1 to 1.19.2.
Thanks for pointing me in the right direction!
@girish thanks, the queue is empty and the dovecot.log only has yesterday and todays events in there. I'll ask the people to do a test, they switched to manual bcc as a workaround atm
The issue here was a tika crash and not solr. Tika processes attachments like PDF/ODT etc. It's unclear why tika itself crashed. The logs are inside the mail container at /run/tika/tika.log if you want to dig into this further. But generally, a retry will pick up things from where it left off the last time around.
