Proxmox-Restore auf einer Crucial BX500: warum er kriecht – und wie er doch durchläuft

Eine Fallstudie aus dem eigenen Homelab: SSD-Tausch unter einer Home-Assistant-VM, drei Fallen, und was auf einer DRAM-losen Budget-SSD einfach normal ist.

TL;DR

Eine DRAM-lose Budget-SSD wie die Crucial BX500 ist als Restore-Ziel zäh, sobald ihr SLC-Cache voll ist. Bei mir kroch ein qmrestore mit ~15 MB/s und brach zweimal ab. Schuld waren nicht die SSD allein, sondern drei Dinge zusammen: eine falsch angelegte Thin-Pool-Chunk-Size, ein soft gemounteter Backup-Share und ein hängender qmrestore, der das Blockgerät blockierte. Nach den Fixes lief der Restore stabil mit ~30 MB/s durch – 178 GB in knapp zwei Stunden. Das ist auf dieser SSD kein Defekt, sondern die Obergrenze.

Ausgangslage

Unter meiner Home-Assistant-VM lag eine einzelne SATA-SSD (SanDisk SSD PLUS 1 TB) als eigener LVM-Thin-Pool – keine Redundanz. Über Wochen häuften sich die Warnzeichen:

• ein reproduzierbarer medium error an immer derselben LBA (46258176), „auto reallocate failed"
• Reported_Uncorrect (SMART 187) stieg langsam weiter an
• der erweiterte SMART-Selbsttest lief kein einziges Mal zu Ende, brach immer mit „Fatal or unknown error" ab

Die Backups liefen zwischenzeitlich wieder sauber – was bei einer marginalen Speicherzelle nichts heißt, die mal liest und mal nicht. Für die Disk, auf der die komplette Haussteuerung liegt, war das genug. Ersatz: eine Crucial BX500 1 TB SATA, weil gerade verfügbar und günstig.

Der Tausch

Alle sechs SATA-Plätze belegt, also Kalttausch: Server herunterfahren, alte SSD raus, BX500 rein, hochfahren. Danach den Thin-Pool neu anlegen und die VM-Disk aus dem letzten vzdump vom Netzwerk-Share zurückholen.

Klingt nach 20 Minuten. Wurde ein halber Tag.

Falle 1: Die Thin-Pool-Chunk-Size, die dir keiner sagt

Mein erster Reflex:

lvcreate -l 100%FREE --type thin-pool -n SSD-Anwendungen-1 SSD-Anwendungen-1

Sieht harmlos aus. Das Problem: ohne explizite Angabe wählt LVM die Chunk-Size selbst – und bei „nimm den ganzen freien Platz" landete ich bei 512 KiB. Jeder kleine Schreibzugriff im Restore wird damit zu einem Read-Modify-Write über einen 512-KiB-Block. Write-Amplification durch die Decke, und auf einer SSD ohne DRAM-Cache trifft das genau die schwächste Stelle. Der Restore lief mit ~15 MB/s und starb irgendwann.

Der Fix ist eine einzige Option – und sie muss zur restlichen Umgebung passen. Meine anderen Pools (und die Proxmox-Standardpools) laufen mit 64k:

lvcreate -L 920G --type thin-pool --chunksize 64k -n SSD-Anwendungen-1 SSD-Anwendungen-1

Danach war dieselbe SSD plötzlich brauchbar. Merke: Chunk-Size immer explizit setzen und über alle Pools gleich halten. Ein lvs -o name,chunk_size auf dem Host zeigt dir, was deine bestehenden Pools nutzen.

Falle 2: Der soft gemountete Backup-Share, der mitten im Restore abbricht

Der zweite Abbruch kam nicht von der SSD, sondern von der Quelle. Mein NAS-Share war mit der Option soft eingebunden. Wenn die betagte NAS unter Last kurz zu langsam antwortet, gibt ein soft-Mount nach dem Timeout einen I/O-Error an die Anwendung zurück – und qmrestore bricht mittendrin ab, mit einer nichtssagenden err -5-Meldung.

hard gemountet blockiert der Zugriff im gleichen Fall stattdessen so lange, bis die NAS wieder antwortet. Genau das will man beim Restore:

pvesm set HDD-WDCloud --options hard

Wenn eine langsame NAS im Spiel ist: Backup-Storage hard mounten. soft fühlt sich im Alltag „robuster" an, ruiniert dir aber genau die eine Operation, bei der es zählt.

Falle 3: Der abgebrochene qmrestore, der das Device festhält

Nach jedem Abbruch wollte ich den Pool neu aufsetzen – und bekam:

Logical volume SSD-Anwendungen-1/vm-600-disk-0 in use.

Obwohl nichts mehr lief. Ein abgeschossener qmrestore lässt einen pbs-restore- bzw. Perl-Worker als Zombie zurück, der das Blockgerät weiter offen hält. Erst den Worker killen, dann das LV freigeben:

pgrep -af "qmrestore:600"
pgrep -f "qmrestore:600" | xargs kill -9
lvchange -an SSD-Anwendungen-1/vm-600-disk-0
lvremove -f SSD-Anwendungen-1/vm-600-disk-0

Danach ließ sich der Pool sauber neu bauen. Nach einem abgebrochenen Restore immer prüfen, ob noch ein Worker das Device hält, bevor man weitermacht – sonst jagt man Geister.

Der Lauf, der klappte – und warum 30 MB/s hier normal sind

Mit 64k-Chunks, hard-Mount und aufgeräumtem Device lief der Restore aus dem vzdump dann stabil mit ~30 MB/s durch: 178 GB in 1 h 51 min, PVE-Task OK, sparse zu ~80 %. VM gestartet, Home Assistant war zurück.

30 MB/s klingt nach kaputt. Ist es hier aber nicht. Die BX500 ist eine DRAM-lose SSD mit SLC-Cache: Solange der Cache reicht, sieht man SATA-typische Werte. Ein voller qmrestore schreibt aber Hunderte GB am Stück – der SLC-Cache ist nach ein paar GB voll, danach schreibt die SSD direkt in den langsamen TLC-Speicher, und bei kleinen, verstreuten Schreibzugriffen bleiben real 15–25 MB/s übrig. Das ist die Bauart, kein Defekt.

Praktische Konsequenz: Als Restore-Ziel unter einer produktiven VM ist so eine SSD grenzwertig. Für ein Datengrab oder eine VM mit wenig Schreiblast ist sie völlig in Ordnung – aber plane den nächsten Ernstfall-Restore mit „das dauert zwei Stunden" ein, nicht „zwanzig Minuten".

Checkliste fürs nächste Mal

• Chunk-Size beim lvcreate --type thin-pool immer explizit (--chunksize 64k) und über alle Pools identisch
• lvs -o name,chunk_size prüfen, bevor man sich wundert
• Backup-Storage von langsamen NAS hard mounten, nicht soft
• Nach jedem abgebrochenen Restore: pgrep -af qmrestore / pbs-restore, Worker killen, erst dann lvremove
• Bei DRAM-losen Budget-SSDs als Restore-Ziel: Restore-Dauer realistisch ansetzen (≈ Kapazität ÷ 20 MB/s)
• Und der eigentliche Lehrsatz: die Disk unter der zentralen VM nicht ohne Redundanz oder zumindest einen geübten Restore-Weg laufen lassen

Das hier ist ein Ausschnitt aus meinen Betriebsnotizen zum Thema „Proxmox + Home Assistant ausfallsicher". Wenn dich der Rest interessiert – Storage-Layout, VLAN-Segmentierung fürs Smart Home, ein Backup-Zeitplan, der wirklich durchläuft – dann hier entlang.