Space issue with HAOS on Proxmox 8

I succesfully created a Proxmox VM running HAOS and it works fine. The problem is that I configured it with a LVM-Thin disk of 64GB, and whenever I make a VM backup, the resulting size is a close to that. On the other hand, the HAOS GUI backup is about 400MB.

Runing the lvs command on Proxmomx shows that the VM disk is 98% full, but I can’t figure out by what.

I tried several commands on the HA terminal to find the largest directories, but nothing larger than a few MB comes up. I guess I’m doing it in the wrong place.

What can I do to find out what takes all the space?

You are probably looking into the SSh & Terminal addon, which is a slim dtand-aæone container with just a few directories mapped into it, like the config directory.
This means you are not seeing the full size of HA.
HA is also just a container and if you have addons then those are containers too and also have a size which is not included in the HA size.

My guess is that it is either the recorder or the long term statistic that eats your disk space.
Download your backup file to your normal workstation and then open it up with a compression app, like WinRAR, 7-Zip or WinZip or similar.
Inside you will find the size of the different addons.
If you are using InfluxDB, then I guess that will be the big one.
If not, then it will be a file called something like homeassistant_db or similar in the Homeassistant container.
Those containers is can also be opened with the same programs.

If it is the InfluxDB or the homeassistant_db file, then you can make a service call to shrink it and repack it.

Go to the developer tools and click the Service tab.
Select “Recorder: Purge” as service call and set the days you want to keep and Mark the repack option and make the call.
The effect might take some hours to be seen, because the task is running with a low priority to not affect the normal work of HA.

Once your recorder is slimmed, then Search the forum and/or web for guides on how to configure your recorder to only record what you need and want.

Just a couple random thoughts for you. Up front, I use Home Assistant under Docker in Linux VM’s under Proxmox. So I do not have direct experience with HAOS as a VM under Proxmox. That said two things I think I remember caused disk ballooning (and incompressible or less compressible backups by Proxmox) with my setups :

  1. using the Linux volume manager inside the VM to create volumes for my VMs seemed to cause Proxmox to have difficulty ‘looking inside’ to optimize the backup compression of a VM’s volume. For a number of reasons to reduce the complexity of my VM’s I do not use Linux LVM under Proxmox.
  2. Docker’s layered file system/storage driver ‘ballooning’ due Docker containers creating massive logs within the docker image (often occurs when the app in the container is crashing and restarting over and over). You end up with a massive file that is the Docker file system inside the VM. When I run into this, so far my only solution is to delete the all the Docker containers wipe the Docker file system and then have to rebuild each Docker container.

If my memory is correct and if HAOS uses one or both of these mechanisms, these might be something to peer into.

Good hunting!

Thanks. This is the content of the last full backup:

And this are the largest files in the config dir:

So I guess the problem is not within the HA ecosystem.

Ok, your database is large, but not by a lot.
One final thought is to look into your backup folder for failed backups.
Sometimes the backup fails and the created file will not be added to the HA list of backups, but it will not be removed either.
You could use the Advanced SSH & Web Terminal addon to look at the backup directory and delete any extra files in that directory.

Thanks! This is the result of the command find -type f -exec du -h {} + | sort -rh | head -n 5 run in the docker container (accessed from the HA terminal using docker exec -it $(docker ps -f name=supervisor -q) bash):

The large files are backups on an external drive, mounted on Proxmox, visible from HA.

Any ideas?

Look into the backup directory specifically.
The files might be smaller than that, but many in quantity.

In looking at the picture of the files you shared:

  1. Not sure what use looking at your proxmox backup files from within the VM is. I would look at the proxmox backups from the proxmox GUI.
  2. That said, the fact that you have what appears to be three backups that took 50+ gb of storage each, and then the 4th which only took 3.4 gb. So what did you change in your VM between the backup on the 3rd March and the backup on the 4th March? The backup size went down from 50 gb to 3 gb?

I am not very familiar with Proxmox, but it might need some tweaks in the virtual disk configuration? In your config, the LVM Thin disk is attached as a “raw” disk to the HAOS VM?

The script shared in Installing Home Assistant OS using Proxmox 8 adds discard=on,ssd=1 to the virtual disk configuration, maybe that helps? :thinking:

FWIW, HAOS runs a fstrim systemd service once a week. This should help for underlying disk systems to understand which blocks are actually free. So after enabling above options, it might take a while for virtual disk/Proxmox to learn which blocks are actually free.

Damn, I must start to read the posts more carefully.
I read it as problems with the size in HA and not with the size of the VM.

A VM stores the files on virtual file system. It stores them as if it was a physical disk and that means it will put them where ever there is space for it.
Because the system also create and delete files all the time, then the system will eventually have files thrown out over the entire file system space.
This means that when Proxmox backs up your VM, then it will backup from the first file to the last file and also all the empty areas in between.
Proxmox can not see the empty areas and it can not repack the disk, so all the files are next to each other without any empty space.

When HA makes a backup, then it see the files and ignore the empty spaces.

  1. Well, the VM can see the Proxmox backup folder because it’s mounted in HA as backup folder too. they use different subdirs. Probably not the best practice…

  2. I didn’t notice the latest backup’s size when posting the screenshot! I’ve just run a new backup and it seems that the new size is correct, at around 3.5 GB. Maybe what posted @agners below did the trick?

Anyway, it looks like it’s solved. Thanks a lot for the help!

Where can I see when fstrim is run? Something happened last night and the size is now magically correct.

I used the LVM-Thin storage type, so it should skip the empty space. Any, it seems resolved now. Thanks for the help.

1 Like

On the VM’s system terminal, you can check the latest run by using login to gain OS shell access, then:

systemctl status fstrim.service

I guess that was it!

Thanks a lot!

1 Like

LVM-Thin reserves space as it is using it, but it will still contain free space between files, because the hypervisor (Proxmox) are not able to see the actual file system inside the VM.

This is exactly where fstrim comes in: It uses modern protocol features of virtualized/paravirtualized block device to tell the underlying hypervisor which blocks are actually unused by the file system inside the VM. This way a thin provisioned block device can actually free up unused disk space.

True, but it is the VM that tells the Hypervisor.

is there any possibility to repack database outside home assistant? I mean download db and repack in PC. There is not enough space on the disk with proxmx where HA is running, repack will end with an error in Proxmox when the disk is full.

Repacking a DB is not like using zip or another compression tool.
A repack means another database is created and every post not marked for deletion is copied over and then the databases are switch around on the server and the old one is deleted.

You have two easy options and that is to give the HA installation a bit more space in Proxmox and then restart HA, which will then automatically claim the extra space or you could do bigger purge, so the repacked database will not contain that much data, but this of course means you will lose some LTS data.