@fortytwo we haven't done anything on your setup, since we don't even have access to your system. I suspect from the logs that there might have been some initial docker hickup on your server, which was resolved by the reboot.

@girish no, they're pretty useless. Their web UI S3 console is such crap it can't handle the chatty API requests and keeps timing out. Also I may be wrong that multiple directories are because of failures and restarts. It just looks like multiple changed apps per day get a new dir.

So I am attempting other workarounds. Like creating a new bucket and just nuking the old one.

rsync isn't great for object store backups as it makes a ton of small files.
tgz isn't great as it's a lot of repeated information.

We need something hybrid that is the best of both.
Something like backing up to a local Minio much more quickly then doing an object to object store transfer offsite, which is much more efficient. This may also offer an opportunity to dedupe and further optimize.

@tx-hermit Ah, here's the explanation - https://serverfault.com/questions/1024770/ubuntu-20-04-time-sync-problems-and-possibly-incorrect-status-information . Uninstalling/disabling ntp service does the trick! I will make a fix for next release.

I think we won't change the minimum requirement tested for in the cloudron-setup script for now. It seem quite the edge case to have that little storage available, however it is good that we know there is a possible workaround for those cases.

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

@timmeh let us know if @NCKNE's workaround works or not.

This comment was very informative - https://bugs.launchpad.net/ubuntu/+source/ansible/+bug/1833013/comments/6 . I didn't realize you have to pass so many options to make it not ask questions.