As the root cause of this was, that the backup was continuing even though the backup disk was not mounted, we were now able to find the bug which caused this and possibly other similar issues.

So the check itself for the mountpoint was correct, but this result was just ignored by the code. This oversight will be fixed for the next release and should avoid such cases for mounted backup volumes in the future.

@mehdi

Yah... Maybe it would be enough just to give the administrator a few controls.

the cron interval the warning level the kill level (kill all modules)

@nebulon Thanks for confirming! 🙂

@girish great thanks, It works 😉

@ei8fdb right the graphs don't update immediately, but every 6 hours or so. Otherwise, the disk spins a lot 🙂

I will mark this thread as solved, but this problem will go away soonish. I think only ~20 apps are left to use the new base image. The 7.1 release also updates all the internal containers to use the latest image. Should all be done end of this month.

@scooke
@murgero

I am working on get my FreeNAS NFS mount working for the backups, but that seems to be a bit difficult to get the permissions working.

If you have experience with NFS, you might have an answer on my problem here...

https://forum.cloudron.io/topic/5927/cloudron-backups-on-truenas-nfs-mount/3?_=1636891033300

However thanks!

@girish

UPDATE: Finally found the culprit the was a huge backup file in /var/backups/snapshot#

Did the internal DNS restart steps, restarted docker and my sites are working again. Still having trouble accessing the cloudron admin page, complaint about certificates etc. will wait and see if this resolves itself.
Dimitri

UPDATE: /home/yellowtent/box/setup/start.sh did the trick cloudron dashboard also available again

@jdaviescoates said in Volume disk space strangeness:

/me goes to reduce the size of the volume back to a perfectly sufficient 10 GB...

Oh, bollocks. You can't decrease the size of Hetzner Cloud Volumes, only increase them. So I'd have to create a whole new one and then and then and then...can't be bothered with all that so I guess I'll just stomach the slightly increased cost of 15 GB over 10 GB.

Debugged this with @ZeZaung a bit. Somehow, it was possible to re-run cloudron-setup on the existing install and this reset the database even though the app containers and data were still there. I have made a fix which should hopefully mitigate the problem.

@girish Seems to be all clear. No got any notification in system area. So alert was it misunderstood?

Many thank's!

@jdaviescoates said in Nextcloud says 5.3GB used, Cloudron says Nextcloud is 19.16GB, why?:

That's "just" a difference of 2.66GB (which I guess could mostly be just Nextcloud files themselves)

So, assuming that is mostly just Nextcloud files themselves (I may do a clean install at some point just to see how big that is), I think this can be marked as solved.

Ah we did hit that kernel/initramfs issue with /boot getting filled up by Ubuntu already before. If it is 100% full even the autoremove fails.

Would be good to actually not just maybe warn about that, but see how the whole situation can be mitigated in the first place. Afterall it is not much use to have that many kernel versions around.

@girish & @marcusquinn thanks for the hints!

Finally the AWS guide did the trick, it was a 2 step approach (in my case):

sudo growpart /dev/sda 3

sudo resize2fs /dev/sda3