@stoccafisso I can confirm that for me this is Rocket.Chat flakiness, not Cloudron. I fear your restoration process won't help if Rocket.Chat is just going to kick off its log filling process again.
@girish I haven't yet tried moving logs to the filesystem, because (very strangely) my Rocket.Chat settings page currently appears to be empty, just a search box:
[image: 1737946754270-6a705bac-8cc0-4a93-9388-5336b1f80132-image.png]
That's a Rocket.Chat mystery I haven't figured out yet.
I did try the scheduled mongodb log clearing idea directly in the app container, but it didn't seem to help. Because I can't see what's actually happening in the database, I don't know if that's because the data is filling up faster than the query runs, or because of database locking because the database is so big (100s of Gb), or something to do with virtual container file system strangeness, or something else.
At this stage my server seems to have fallen into this pattern:
Rocket.Chat fills the disk
Rocket.Chat attempts an update (I have auto updates on)
Update fails because the backup fails (no disk space to prepare the backup, even though my backups go offsite to Backblaze)
Rocket.Chat restarts, at which point the "filled" disk space moves from within the Rocket.Chat container to the virtual file system (reported as "everything else" on the Cloudron System Info page)
A reboot releases the disk space from the virtual file system
Start over...
The disk filling doesn't seem to start immediately any more. I don't know what triggers it.
So that means with a reboot every day or so, the server is more or less operational for general usage, except for a while right at the end when the disk is full.
I'm hoping a Rocket.Chat update will arrive soon that makes this go away.