Yes, this is the resolution
2. Why the Proxmox backup grows every week
This is probably the main reason, and it has little to do with space usage within HA. When HAOS deletes a file – for example, yesterday’s HA backup (your /backup directory was modified at 00:01 today, so daily backups are running) – the blocks are only freed up for the file system. The virtual disk in Proxmox is unaware of this as long as no TRIM/Discard is passed through. New data is then written to blocks that are still unused, and vzdump backs up all blocks that have ever been written to. The image thus slowly fills up towards 32 GB, even though only 13 GB are actually in use.
Solution:
Proxmox → VM → Hardware → Hard Disk → Edit → Advanced: Enable Discard (it’s also advisable to enable ‘SSD emulation’).
Shut down the VM completely and restart it. A reboot from HA is not sufficient.
On the HAOS host (see below for access details), run a single trim command:
fstrim -av
Afterwards, the next Proxmox backup should be significantly smaller, roughly the size of the data actually in use.
3. Accessing the underlying HAOS
The easiest way is via the Proxmox console: Open the VM console in Proxmox. At the ha > prompt, type:
login
4. Analysis on the host
df -h /mnt/data
du -xh -d1 /mnt/data | sort -h
du -xh -d1 /mnt/data/docker | sort -h
docker system df
docker image ls
journalctl --disk-usage
5. Tidying up
Remove Docker images that are no longer in use (images of running or stopped add-ons will be retained):
docker image prune -a
Limit the journal:
journalctl --vacuum-size=200M
Afterwards, run fstrim -av again to ensure that the freed-up space is also recognised by Proxmox.
One more note: Your HA internal backups (1.8 GB in /backup) are included in every Proxmox backup. If you’re backing up via Proxmox anyway, it’s worth reducing the retention period for the HA backups or moving them to a network drive (Settings → System → Storage → Network Storage).
It is normal for fstrim.service not to run after a reboot. It is a one-off service: it starts, performs a single trim operation, and then stops. It is not intended to run continuously. It is triggered automatically via fstrim.timer.
You can check the timer on the HAOS host as follows:
systemctl status fstrim.timer
systemctl list-timers | grep fstrim
Unfortunately, running systemctl enable usually has no effect on HAOS. The root filesystem is read-only, and changes made to /etc/systemd/system generally do not survive a reboot or OS update.
The permanent solution: Trigger trim from within Proxmox
HAOS includes the QEMU Guest Agent. Proxmox can use this to trigger trim in the guest, regardless of HAOS updates.
Proxmox → VM → Options → Enable QEMU Guest Agent. Also tick the box for ‘Run guest-trim after a disk move or VM migration’.
Shut down the VM completely and restart it.
Test on the Proxmox host (replace 100 with your VM ID):
qm guest cmd 100 fstrim
The output shows the number of bytes trimmed per file system.
4. Set this up as a cron job on the Proxmox host using crontab -e:
0 2 * * 0 /usr/sbin/qm guest cmd 100 fstrim >/dev/null 2>&1
This runs every Sunday at 2.00 am. It’s best to schedule it just before your weekly Proxmox backup, so that the backup is always ‘lean’.
If you want to synchronise it very closely with the backup, you can also do this via a vzdump hook script in the ‘backup-start’ phase. However, the cron job is perfectly adequate for your weekly schedule.
).