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:
- 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.
- 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? 
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.
-
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…
-
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
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.
thanks for the info, I was hoping that it could be done with some command, just as I was able to fix the databases thanks to the HA forum (forum ). Unfortunately, in Proxmox I can’t give HA more space, so I can’t do that, I can’t change the size of Local-lvm (although I asked about it on the proxmox forum, that procedure is beyond my experience)
i found sqlite VACUUM command this is like repacking in HA?
If you have the space on the disk, then it is easy in Proxmox to add a bit more to the VM.
Just remember that the value you in the next window is the space you want to add and not the space you want as a total for the VM.
Just restart the HA host and not just the core afterwards and HAOS will do the rest.
yes I know this, I increased it, but my local-lvm fills up,
I don’t have disk space, I have 80GB of free space on my local disk, but I can’t convert this disk space to local-lvm, I got advice on the proxmox forum, but that’s beyond my skills