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!

I see. So, anything in the logs?

omg.thanks - I really thought I did that... working now

Thank you very much for the reply. I’ve implemented it, and the issue is resolved. Regards.

There's nothing to be embrass - It's still a great platform! So thank's .)

@james Thanks ~!

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

Yes I updated yesterday to 10.0.5 That may explain I didn't had the issue in the scheduled backup not in the manual I have tried. Thanks for the fix

Thanks for reporting, fixed - https://git.cloudron.io/platform/box/-/commit/dcfb4d0832cd336fd9d46b0f9dd38f65dd5ae981

@nanogabi thanks for the report, it is spot on. I have fixed it for the next release - https://git.cloudron.io/platform/box/-/commit/57ef2c2fd3baf161f45c1402e3526222998e9b6f

Hello @mpevhgnuragistes Glad to see that your issue is resolved. Still, your Cloudron is very outdated and you should update it.

[image: image.jpeg]

Hello @umnz You can also run cloudron --help to show all function of the cloudron cli.

Thank you for your help, I'll try this!

The difference is just a technical one, where we solve a potential case of misalignment, not a change in behavior. I don't think there is much to document as such. I guess one can see the previous flow as a bug which got fixed.

Oh so you guys did change the pricing. Are we grandfathered at the account level or at the existing plan level? Nevermind. The answer is a few posts above this. (I didn't originally read that far)

Hello @arta On what Cloudron version are you now exactly? Have you tried clearing the cache? Also, how many users and groups are on this system?