Hier greifen zwei getrennte Effekte ineinander. Deshalb passen die Zahlen nicht zusammen.
1. Warum dein du nur 4 GB zeigt
Die SSH-Session läuft nicht auf dem eigentlichen Betriebssystem. Sie läuft in einem Add-on-Container. Du siehst dort nur das Container-Dateisystem und die eingehängten Ordner (/homeassistant, /backup, /share usw.). Der größte Teil der Datenpartition ist von dort aus unsichtbar:
-
Docker-Images und -Layer von Core, Supervisor, Plugins und Add-ons, inklusive alter Versionen nach Updates
-
das Systemd-Journal (persistente Logs)
-
Supervisor-interne Daten
All das zählt HA in der Anzeige als „System“, also die 9,9 GB.
2. Warum das Proxmox-Backup jede Woche wächst
Das ist vermutlich der Hauptgrund, und er hat mit der Belegung innerhalb von HA wenig zu tun. Wenn HAOS eine Datei löscht, zum Beispiel das gestrige HA-Backup (dein /backup wurde heute um 00:01 geändert, es laufen also tägliche Backups), sind die Blöcke nur für das Dateisystem frei. Die virtuelle Disk in Proxmox erfährt davon nichts, solange kein TRIM/Discard durchgereicht wird. Neue Daten landen dann in noch unbenutzten Blöcken, und vzdump sichert alle jemals beschriebenen Blöcke mit. Das Image wächst so langsam Richtung 32 GB voll, obwohl nur 13 GB tatsächlich belegt sind.
Lösung:
-
Proxmox → VM → Hardware → Festplatte → Bearbeiten → Erweitert: Discard aktivieren (zusätzlich „SSD-Emulation“ ist sinnvoll).
-
Die VM komplett herunterfahren und neu starten. Ein Reboot aus HA heraus reicht nicht.
-
Auf dem HAOS-Host (Zugang siehe unten) einmal trimmen:
fstrim -av
Danach sollte das nächste Proxmox-Backup deutlich kleiner sein, ungefähr in der Größe der tatsächlich belegten Daten.
3. Zugang zum darunterliegenden HAOS
Am einfachsten über die Proxmox-Konsole: Öffne die VM-Konsole in Proxmox. Am Prompt ha > tippst du:
login
Damit hast du eine Root-Shell direkt auf dem HAOS-Host, ohne Passwort.
Alternativ gibt es SSH auf Port 22222 (Developer-Zugang). Dafür musst du einen authorized_keys-Key importieren, was in einer VM umständlicher ist. Für eine Analyse reicht die Konsole.
4. Analyse auf dem 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. Aufräumen
Nicht mehr benutzte Docker-Images entfernen (Images laufender oder gestoppter Add-ons bleiben erhalten):
docker image prune -a
Journal begrenzen:
journalctl --vacuum-size=200M
Danach nochmal fstrim -av, damit der freigewordene Platz auch in Proxmox ankommt.
Noch ein Hinweis: Deine HA-internen Backups (1,8 GB in /backup) werden im Proxmox-Backup jedes Mal mitgesichert. Wenn du ohnehin per Proxmox sicherst, lohnt es sich, die Aufbewahrung der HA-Backups zu verkürzen oder sie auf ein Netzlaufwerk auszulagern (Einstellungen → System → Speicher → Netzwerkspeicher).
Wenn du mir die Ausgabe von du -xh -d1 /mnt/data und docker system df schickst, kann ich dir genau sagen, woraus die 9,9 GB bestehen.
Dass fstrim.service nach einem Reboot nicht läuft, ist normal. Es ist ein Oneshot-Dienst: Er startet, trimmt einmal und beendet sich. Er soll gar nicht dauerhaft laufen. Automatisch ausgelöst wird er über fstrim.timer.
Den Timer prüfst du auf dem HAOS-Host so:
systemctl status fstrim.timer
systemctl list-timers | grep fstrim
Ein systemctl enable bringt auf HAOS leider meist nichts. Das Root-Dateisystem ist schreibgeschützt, und Änderungen unter /etc/systemd/system überleben ein Reboot oder OS-Update in der Regel nicht.
Die dauerhafte Lösung: Trim von Proxmox aus anstoßen
HAOS bringt den QEMU Guest Agent mit. Darüber kann Proxmox den Trim im Gast auslösen, unabhängig von HAOS-Updates.
Proxmox → VM → Optionen → QEMU Guest Agent aktivieren. Setze dort auch den Haken bei „Run guest-trim after a disk move or VM migration“.
Die VM einmal komplett stoppen und wieder starten.
Auf dem Proxmox-Host testen (ersetze 100 durch deine VM-ID):
qm guest cmd 100 fstrim
Die Ausgabe zeigt die getrimmten Bytes pro Dateisystem.
4. Als Cronjob auf dem Proxmox-Host einrichten mit crontab -e:
0 2 * * 0 /usr/sbin/qm guest cmd 100 fstrim >/dev/null 2>&1
Das läuft jeden Sonntag um 2:00 Uhr. Leg die Zeit am besten kurz vor dein wöchentliches Proxmox-Backup, dann ist das Backup immer „schlank“.
Wenn du es ganz eng an das Backup koppeln willst, geht das auch über ein vzdump-Hookscript in der Phase backup-start. Für deinen wöchentlichen Rhythmus reicht der Cronjob aber völlig.
