> ## Content Index > Fetch the complete content index at: https://lab.mackedanz.net/llms.txt > Use this file to discover other available public pages before exploring further. # Proxmox-Restore auf einer Crucial BX500: warum er kriecht – und wie er doch durchläuft - URL: https://lab.mackedanz.net/proxmox-restore-crucial-bx500/ - Published: 2026-09-07T16:47:14.000Z - Updated: 2026-09-07T16:52:14.000Z - Description: SSD-Tausch unter der Home-Assistant-VM: drei Fallen (Chunk-Size, soft-Mount, hängender qmrestore) – und warum 30 MB/s auf einer DRAM-losen SSD normal sind. - Author: Michael Mackedanz - Tags: Proxmox, Backup, Storage, Homelab *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*](#/portal/signup)*.*