ZFS unter Proxmox betreiben: ARC, Snapshots, Scrubs

ZFS ist unter Proxmox für viele die Standardwahl: Prüfsummen auf allen Daten, Snapshots ohne Wartezeit, Replikation zwischen Knoten. Dafür verlangt es etwas Pflege, die bei ext4 nicht nötig ist. Wer die drei Stellschrauben kennt, Arbeitsspeicher, Aufbau des Pools und Scrubs, hat damit jahrelang Ruhe.

Wie viel Arbeitsspeicher ZFS nimmt#

ZFS hält einen Lesecache im Arbeitsspeicher, den ARC. Er wächst, solange Speicher frei ist, und gibt ihn wieder ab, wenn Programme ihn brauchen. Auf einem Proxmox-Knoten konkurriert er aber mit den VMs, und das Abgeben geht nicht immer schnell genug.

arc_summary | head -30
# oder knapp:
awk '/^size|^c_max/ {printf "%s %.1f GiB\n", $1, $3/2^30}' /proc/spl/kstat/zfs/arcstats

size ist die aktuelle Größe, c_max die Obergrenze. Seit Proxmox VE 8.1 setzt der Installer bei Neuinstallationen eine Grenze von 10 % des Arbeitsspeichers, höchstens 16 GiB. Ältere oder hochgezogene Installationen haben oft keine Grenze, dann darf der ARC bis zur Hälfte des Arbeitsspeichers wachsen.

Eine eigene Grenze setzt du so, hier 8 GiB:

echo "options zfs zfs_arc_max=$((8 * 1024**3))" > /etc/modprobe.d/zfs.conf
update-initramfs -u -k all
# sofort wirksam, ohne Neustart:
echo $((8 * 1024**3)) > /sys/module/zfs/parameters/zfs_arc_max

Wie groß? Als Ausgangspunkt nennt die Proxmox-Dokumentation 2 GiB plus 1 GiB je TiB Speicherplatz im Pool. Danach beobachten: Ist die Trefferquote im ARC hoch (in arc_summary unter „Cache hit ratio“) und der Speicher knapp, darf er kleiner werden.

Den Pool richtig aufbauen#

Die Entscheidung fällt einmal, beim Anlegen, und lässt sich später nur mit Umkopieren ändern.

RAIDZ ist für VM-Platten meist die schlechtere Wahl. Ein RAIDZ-Verbund liefert bei kleinen, zufälligen Zugriffen ungefähr die Leistung einer einzelnen Platte, und genau solche Zugriffe erzeugen VMs. Spiegel skalieren mit der Anzahl der Paare.

Zwei Regeln, die beim Anlegen zählen:

• ashift=12 für aktuelle Platten mit 4K-Sektoren. Der Proxmox-Installer setzt das; bei Handarbeit mit zpool create -o ashift=12 … angeben. Lässt sich später nicht ändern.
• Kein Hardware-RAID darunter. ZFS braucht direkten Zugriff auf die einzelnen Platten, sonst sieht es Fehler nicht. Controller in den HBA- oder IT-Modus schalten.

Kompression ist bei Proxmox standardmäßig an (lz4 bzw. zstd) und kostet praktisch nichts. Lass sie an.

Snapshots#

zfs list -t snapshot
zfs snapshot rpool/data/vm-101-disk-0@vor-update
zfs rollback rpool/data/vm-101-disk-0@vor-update
zfs destroy rpool/data/vm-101-disk-0@vor-update

Für VMs nimmst du besser den Weg über Proxmox (qm snapshot 101 vor-update), weil der auch die VM-Konfiguration und auf Wunsch den Arbeitsspeicherzustand sichert.

Scrubs: die Daten regelmäßig lesen#

Ein Scrub liest alle Daten im Pool und vergleicht sie mit ihren Prüfsummen. Findet er einen Fehler, repariert er ihn aus dem Spiegel oder der Parität. So fallen schleichend beschädigte Sektoren auf, bevor die zweite Kopie auch betroffen ist.

Debian und Proxmox planen einen Scrub bereits ein: /etc/cron.d/zfsutils-linux startet ihn am zweiten Sonntag jedes Monats. Prüfen, ob er gelaufen ist:

zpool status -v

Die Zeile scan: zeigt den letzten Scrub und ob er Fehler repariert hat. errors: No known data errors ist der Zielzustand.

Erfahren, dass eine Platte stirbt#

zpool status -x          # „all pools are healthy" oder eine Beschreibung des Problems

Ein DEGRADED bedeutet: Eine Platte fehlt oder ist ausgefallen, der Pool läuft ohne Redundanz. Das muss dich erreichen, nicht erst beim nächsten zufälligen Blick. Der ZFS-Ereignisdienst ZED kann Mails verschicken:

# /etc/zfs/zed.d/zed.rc
ZED_EMAIL_ADDR="[email protected]"
ZED_NOTIFY_VERBOSE=1

systemctl restart zfs-zed

Das setzt einen funktionierenden Mailversand auf dem Knoten voraus. Proxmox richtet dafür Postfix ein; unter Datacenter → Notifications lässt sich festlegen, wohin es geht. Zusätzlich lohnt ein Blick auf die SMART-Werte der Platten (smartctl -a /dev/sdX), mehr dazu in Monitoring, das dich auch nachts erreicht.

Eine Platte tauschen#

zpool status rpool                     # welche Platte fehlt?
ls -l /dev/disk/by-id/ | grep -v part  # neue Platte finden
zpool replace rpool <alte-id> /dev/disk/by-id/<neue-id>
zpool status rpool                     # Resilver läuft

Ist der Pool der Bootpool des Proxmox-Knotens, müssen auf der neuen Platte zusätzlich Partitionen und Bootloader eingerichtet werden (proxmox-boot-tool). Der Ablauf steht in der Proxmox-Dokumentation unter „ZFS on Linux“, Abschnitt zum Tausch eines bootfähigen Geräts. Nicht aus dem Gedächtnis machen.

Häufige Fragen#

Mein Speicher ist fast voll, obwohl die VMs wenig belegen. Warum?#

Meist der ARC. free -h zählt ihn als belegt, obwohl er Cache ist. Mit der Abfrage oben siehst du, wie viel davon ZFS gehört. Wird es wirklich eng, setzt du die Grenze niedriger.

Wie voll darf ein Pool werden?#

ZFS wird langsamer, je voller der Pool ist. Als Faustregel gilt: ab etwa 80 % Belegung planen, nicht erst bei 95 %. zpool list zeigt die Belegung in der Spalte CAP.

Swap auf ZFS?#

Besser nicht. Unter Speicherdruck kann das hängen, weil ZFS selbst Speicher braucht, um zu schreiben. Swap gehört auf eine eigene Partition oder bleibt weg, siehe Speicher knapp.

ZFS oder LVM-Thin?#

Beides funktioniert. Die Abwägung steht in Proxmox-Storage: welcher Typ wofür.

Kurz gesagt#

• Der ARC wächst in den freien Speicher. Grenze in /etc/modprobe.d/zfs.conf setzen.
• Spiegel für VMs, RAIDZ für Sicherungen und große Dateien.
• ashift=12, kein Hardware-RAID, Kompression an lassen.
• Snapshots sind ein Rückweg, keine Sicherung.
• Scrubs laufen monatlich; zpool status -x und ZED-Mails sagen dir, wenn eine Platte ausfällt.