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, ohne 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. 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, sie muss aber 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, bekam aber:

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, und 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