Cloudron Forum

Update: cloudron-support --troubleshoot returns:

[WARN] netplan configuration is empty. this might be OK depending on your networking setup [FAIL] DNS is not resolving

Further, /etc/netplan/ is empty. How do I generate the correct .yaml file to include there?

Final Update: I was able to crate a netplan .yaml file by following these instructions.

Most of the time the scheduled backups now succeed, but not always.
I'll keep an eye on the backups and make manual backups if the scheduled failed.

Let's see if the changes of scaleway improve the situation.

Thanks again for the suggestions and help.

I would not do this with backups for all the reasons @girish has mentioned (ie you'd have to restore the objects to standard before you'd be able to use them and this could take a while, not what you want when you need to quickly restore a backup), but what you could do if you really wanted to is to move older backups to Glacier automatically after a certain amount of time using automated lifecycle rules

IMG_20230210_214239.jpg

So is this then fixed by now with getting unbound back alive?

@scooke I tried "cleaning" but didn't make a difference.
Will keep an eye on it.

it's solved, it was a problem with resolv.conf. The DNS servers of my scaleway instance are not responding anymore ... 😞

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