Warum Consumer-SSDs in Proxmox sterben und welche wirklich taugen

Im Proxmox-Forum tauchen sie regelmäßig auf: Threads, in denen eine frisch installierte Consumer-SSD nach wenigen Monaten Betrieb einen zweistelligen Wearout-Prozentsatz anzeigt, obwohl kaum spektakuläre Lastspitzen gefahren wurden. Ein dokumentierter Fall zeigt eine Samsung 980 Pro mit 2 Tb Nennkapazität bei 2 Prozent Wearout nach vier Monaten, mit 86 GB Schreiblast pro Tag in einem gewöhnlichen Homelab-Betrieb. Das klingt nach wenig, hochgerechnet auf die TBW-Angabe des Herstellers ist es aber ein Tempo, das die kalkulierte Lebensdauer auf wenige Jahre statt der beworbenen fünf bis zehn drückt. Der Grund dafür liegt selten am Laufwerk allein. Er liegt in der Kombination aus dem, was Proxmox im Hintergrund ohnehin schreibt, und dem, was ZFS aus dieser Schreiblast macht. Wenn Sie noch grundsätzlich zwischen Proxmox und einer anderen Virtualisierungsplattform abwägen, lesen Sie zuerst unseren Überblick zu Proxmox als Alternative zu VMware ESXi, dieser Artikel hier setzt einen laufenden Proxmox/ZFS-Host voraus.

Die kurze Antwort

Consumer-SSDs verschleißen unter Proxmox schneller, weil der Host auch ohne laufende VMs kontinuierlich kleine, überwiegend synchrone Schreibvorgänge erzeugt (Cluster-Dateisystem, HA-Dienste, Metriken), und ZFS diese Schreiblast durch Copy-on-Write und Metadaten zusätzlich vervielfacht. Ohne Power Loss Protection muss eine SSD jeden dieser sync-Writes sofort und einzeln ins NAND programmieren, was in unabhängigen Benchmarks einen Faktor von rund 130 bei der sync-Schreibrate ausmacht. Wer nicht kaufen will, kann mit HA-Diensten abschalten, korrektem volblocksize und ausgelagerten Logs spürbar gegensteuern, siehe Erst konfigurieren, dann kaufen. Wer eine neue SSD braucht, sollte PLP als Ausschlusskriterium behandeln, siehe Konkrete Empfehlungen. Wer nur gelegentlich Wearout-Sorgen hat, findet unter Die günstigere Alternative vielleicht die passendere Antwort als eine 300-Euro-SSD.

Was Proxmox eigentlich die ganze Zeit schreibt

Ein Proxmox-Host, auf dem keine einzige VM läuft, ist trotzdem nicht im Ruhezustand. Auf der pve-devel-Mailingliste hat ein Nutzer das direkt gemessen: dauerhaft über 10 kB/s und über 10 Schreibvorgänge pro Sekunde allein durch das Cluster-Dateisystem, hochgerechnet auf mehrere hundert Gigabyte Diskblöcke und weit über 100 Millionen IOPS pro Jahr. Das ist keine Ausnahmemessung, sondern ein strukturelles Verhalten von Proxmox selbst.

pmxcfs: das Cluster-Dateisystem schreibt auch im Leerlauf

pmxcfs hält die Cluster-Konfiguration in einer SQLite-Datenbank unter /var/lib/pve-cluster/config.db und repliziert Änderungen per Corosync auf alle Knoten in Echtzeit. Auf der genannten Mailingliste fand sich zusätzlich ein konkreter Bug-Beleg: 331 identische Kopien desselben RSA-Private-Keys und 114 identische SSH-Host-Keys im WAL-Journal, weil pmxcfs unveränderte Daten wiederholt wegschreibt statt selektiv zu aktualisieren. Proxmox-Entwickler Thomas Lamprecht bestätigte in seiner Antwort, dass ihm das „etwas seltsam“ vorkomme, ordnete den größeren Teil der Dauerschreiblast aber den HA-Diensten zu.

HA-Dienste, pvestatd und rrdcached

Laut Lamprecht sind die Hauptverursacher die pve-ha-lrm- und pve-ha-crm-Dienste, die auf jedem Knoten regelmäßig ihren Status aktualisieren, „oft erforderlich, um dem aktuellen Cluster-Resource-Manager den eigenen Zustand zu signalisieren“. Er bezeichnet das ausdrücklich als „required and intentional“, räumt aber Optimierungspotenzial ein, das er als „nicht ganz trivial“ einordnet. Dazu kommt pvestatd, das laufend Statusdaten sammelt, und rrdcached, das diese Daten für die Graphen im Webinterface periodisch auf die Platte schreibt. Wer im Proxmox-Forum nach „rrdcached writes“ sucht, findet Nutzer, die das Flush-Intervall über /etc/default/rrdcached und den Parameter WRITE_TIMEOUT verlängert haben, siehe weiter unten für die Details und einen wichtigen Haken bei aktuellen PVE-Versionen.

Logging und journald

Klassisches syslog- und journald-Logging trägt zur Dauerschreiblast bei, typischerweise in kleinerem Umfang als pmxcfs und HA, aber ebenfalls kontinuierlich und überwiegend synchron, weil Log-Zeilen zeitkritisch persistiert werden sollen. In der Praxis ist die Größenordnung stark abhängig von Log-Level und Anzahl der Dienste, eine belastbare allgemeingültige GB/Tag-Zahl dafür wurde in der Recherche nicht gefunden und wird hier bewusst nicht erfunden.

Wer seinen Proxmox-Host zusätzlich per VXLAN oder in einer Hetzner-Cloud-Umgebung betreibt, kennt das Schreibverhalten unter Umständen noch von einer anderen Seite: In unserem Artikel Hetzner Cloud, MikroTik CHR und Proxmox per VXLAN verbinden spielt die gleiche Grundfrage nach Cluster-Kommunikation und Overhead ebenfalls eine Rolle, dort allerdings netzwerkseitig statt storage-seitig.

ZFS macht aus wenig Schreiblast viel Schreiblast

Write Amplification verstehen

Write Amplification bezeichnet das Verhältnis zwischen den Bytes, die eine Anwendung tatsächlich schreiben wollte, und den Bytes, die am Ende physisch auf dem Flash landen. ZFS erhöht dieses Verhältnis strukturell durch Copy-on-Write (geänderte Blöcke werden nie in-place überschrieben, sondern neu geschrieben), durch Metadaten (Checksums, Baumstrukturen) und durch das ZFS Intent Log (ZIL), das synchrone Schreibvorgänge zusätzlich absichert.

volblocksize, recordsize und ashift

Der größte einzelne Hebel in dieser Kette ist eine falsch gesetzte volblocksize. Ein dokumentierter Benchmark zeigt beim Wechsel von 8K auf 64K volblocksize +106 Prozent Random-Write-Speed und +107 Prozent IOPS. In einem RAIDZ1 mit fünf Platten und ashift=12 lag der Overhead bei 8K volblocksize bei +100 Prozent, bei 32K nur noch bei +25 Prozent. Ein Nutzer hat in einer Kette aus Pool (ashift=12) über Zvol (8K, raw) bis ext4 einen Amplifikationsfaktor von rund 10× zwischen Gastsystem-Schreibvorgängen und tatsächlichen physischen Schreibvorgängen gemessen.

Wichtig für Proxmox-Nutzer: Proxmox setzt beim Anlegen eines Zvols standardmäßig volblocksize=8K, obwohl der OpenZFS-Upstream-Default seit Version 2.2 bereits auf 16K angehoben wurde. Das ist eine bewusste Abweichung von Proxmox, keine veraltete Doku. Historisch war 8K für Sun-Hardware mit 8K-Page-Size sinnvoll, auf x86_64 mit 4K-Page-Size und 4K-NVMe-Blockgröße erzeugt dieser Wert unnötige Fehlausrichtung. Prüfen Sie die tatsächliche Blockgröße Ihres Gastsystems (bei den meisten Linux-Dateisystemen und NTFS 4K) und setzen Sie volblocksize beim Anlegen neuer Zvols entsprechend, eine nachträgliche Änderung an bestehenden Zvols ist nicht möglich, nur beim Neuanlegen.

Warum sync Writes das eigentliche Problem sind

Nicht jeder Schreibvorgang ist gleich teuer. Asynchrone Writes darf ZFS im laufenden Betrieb sammeln und gemeinsam commiten. Synchrone Writes müssen dagegen, POSIX-Semantik entsprechend, vor der Rückmeldung an den Aufrufer tatsächlich sicher persistiert sein. Genau diese Sorte Schreibvorgang erzeugt pmxcfs, und genau bei dieser Sorte Schreibvorgang entscheidet sich, ob eine SSD mit oder ohne Power Loss Protection im Vorteil ist.

Power Loss Protection: der eine Unterschied, der zählt

Eigene Grafik: Schreibpfad vom Gastsystem über ZFS bis zur NAND-Zelle, mit und ohne Power Loss Protection.

Wenn eine Anwendung einen sync-Write auslöst, muss die Firmware der SSD entscheiden, wann sie die Bestätigung zurückgibt. Eine SSD ohne Power Loss Protection darf diese Bestätigung erst geben, nachdem die Daten tatsächlich im nichtflüchtigen NAND gelandet sind, denn ein flüchtiger DRAM-Cache würde die Daten bei einem Stromausfall verlieren. Jede noch so kleine Transaktion erzwingt dadurch eine vollständige NAND-Seiten- oder Blockprogrammierung. Eine SSD mit echter Power Loss Protection besitzt eine Kondensatorbank, die im Fall eines Stromausfalls genug Energie speichert, um den Inhalt des DRAM-Caches noch aktiv ins NAND zu sichern. Dadurch darf die Firmware den sync-Write sofort nach Ablage im Cache bestätigen und mehrere kleine Writes zu größeren, effizienteren Schreibvorgängen bündeln.

Die Kondensatorbank ist der schaltungstechnische Unterschied zwischen Marketing-Begriff und echter Power Loss Protection. (KI-generierte Illustration, kein Foto eines realen Produkts)

Der quantitative Unterschied ist erheblich. Ein unabhängiger fio-Benchmark (Small-Datum-Blog, 16-KB-Writes mit fsync je Schreibvorgang) misst bei einer Samsung 990 Pro ohne PLP nur 325 bis 333 sync-Schreibvorgänge pro Sekunde, bei einer Enterprise-SSD mit PLP (Samsung PM9a3) dagegen 44.500 bis 45.400, ein Faktor von rund 130. Bemerkenswert: Selbst ein Consumer-Laufwerk mit beworbenem PLP-Feature (Crucial T500) erreichte in diesem Test nur 1.083 bis 1.085 Schreibvorgänge pro Sekunde, weit entfernt von echten Enterprise-Werten.

# Grober Testaufbau für einen eigenen Vergleich, Werte variieren je nach Laufwerk und System
fio --name=synctest --filename=/dev/nvme1n1 --direct=1 --rw=randwrite \
    --bs=4k --iodepth=1 --sync=1 --fsync=1 --runtime=30 --time_based

Beispielhafte Kommandozeile zum Nachstellen des Prinzips, keine Ausgabe eines konkreten Testlaufs, da uns für einen direkten Vergleich kein zweites Laufwerk mit PLP zum Gegentesten zur Verfügung stand. Die zitierten Zahlen oben stammen aus dem unabhängig veröffentlichten Small-Datum-Benchmark, nicht aus einem eigenen Testlauf.

Wichtig für die Kaufentscheidung: Nicht jedes Laufwerk, auf dessen Datenblatt „Power Loss Protection“ oder „Power Loss Data Protection“ steht, meint dasselbe. Bei vielen Consumer-Modellen schützt diese Funktion nur die FTL-Mapping-Tabelle, damit das Laufwerk nach einem Stromausfall überhaupt wieder bootfähig und lesbar ist, nicht aber die Nutzdaten, die noch im Schreib-Cache liegen. Echte Enterprise-PLP sichert per Kondensatorbank aktiv den kompletten Cache-Inhalt. Datenblätter von Enterprise-Modellen wie dem Kingston DC600M nennen das explizit „hold-up capacitors“, mit einer Pufferzeit von etwa 10 bis 50 Millisekunden laut Hardware-Whitepapers, in denen die Firmware den Cache aktiv wegschreibt.

Messen Sie Ihren eigenen Zustand

SMART-Werte richtig lesen (SATA und NVMe getrennt)

Bei SATA-SSDs stehen die relevanten Werte unter herstellerabhängigen SMART-Attribut-IDs, meist Wear_Leveling_Count (177), Media_Wearout_Indicator (233) oder Available_Reservd_Space (232):

smartctl -a /dev/sda | grep -E "Wear_Leveling|Media_Wearout|Available_Reservd"

177 Wear_Leveling_Count     0x0013   095   095   000    Pre-fail  Always   -    120
233 Media_Wearout_Indicator 0x0032   095   095   000    Old_age   Always   -    0
232 Available_Reservd_Space 0x0033   100   100   010    Pre-fail  Always   -    0

Beispielhafte Ausgabe zur Illustration des Formats, keine Aufnahme eines konkreten Geräts.

Data Units Written in echte Terabyte umrechnen

Bei NVMe-Laufwerken gibt die NVMe-Spezifikation Data Units Written in Einheiten von 1000 × 512 Byte an, aufgerundet gemeldet. Ein gemeldeter Wert von 1 bedeutet also irgendwo zwischen 1 und 1000 dieser Einheiten:

nvme smart-log /dev/nvme0 | grep -E "data_units_written|percentage_used"

data_units_written             : 45,821,204
percentage_used                 : 12%

Beispielhafte Ausgabe zur Illustration des Formats.

Die Umrechnung in Byte: gemeldeter Wert × 1.000 × 512 = Byte, vereinfacht × 512.000 Byte. Für das Beispiel oben: 45.821.204 × 512.000 Byte ≈ 23,5 TB geschrieben. percentage_used ist eine herstellerspezifische Schätzung des verbrauchten Endurance-Budgets, 100 Prozent entspricht der vom Hersteller kalkulierten Lebensdauer, nicht zwingend einem tatsächlichen Ausfall.

Wer schreibt gerade: iotop, zpool iostat, iostat

Um die tatsächlichen Verursacher zu identifizieren, statt nur die Symptomzahl zu sehen:

zpool iostat -vy 5

                                 capacity     operations     bandwidth
pool                          alloc   free   read  write   read  write
-----------------------------  -----  -----  -----  -----  -----  -----
rpool                          412G   1.1T      2     84   180K  6.2M
  mirror-0                     412G   1.1T      2     84   180K  6.2M
    nvme-eui.0025385...-part3      -      -      1     42    90K  3.1M
    nvme-eui.0025386...-part3      -      -      1     42    90K  3.1M

iotop -ao

  PID  USER     DISK WRITE  SWAPIN     IO>    COMMAND
 1287  root       184.20 K/s   0.00 %  0.00 % pmxcfs
 1512  root        66.40 K/s   0.00 %  0.00 % rrdcached
 1498  root        12.10 K/s   0.00 %  0.00 % pvestatd

Beispielhafte Ausgaben zur Illustration des Formats und der typischen Verursacher, keine Aufnahme eines konkreten Systems.

TBW und DWPD: Restlebensdauer hochrechnen

TBW (Total Bytes Written) ist die vom Hersteller garantierte Gesamtschreibmenge über die Garantiezeit, DWPD (Drive Writes Per Day) das Äquivalent als täglich volle Laufwerksfüllungen. Aus unserer Produktrecherche für diesen Artikel: Consumer-SATA-SSDs liegen meist zwischen 150 und 600 TBW (z. B. Crucial MX500 500GB: 150 TBW, Samsung 870 EVO 1TB: 600 TBW, Crucial MX500 1TB trotz gleicher Kapazitätsklasse nur 360 TBW), Enterprise-Modelle mit PLP typischerweise bei 1 DWPD über fünf Jahre, was bei 1,92 TB Kapazität rund 3.500 TBW entspricht, teils deutlich mehr bei Mixed-Use-Modellen. Simple Faustformel: gemessene TB/Tag × 365 × 5 gegen die TBW-Angabe des Herstellers halten, um eine grobe Restlebensdauer-Schätzung zu bekommen. Das ist eine Näherung, keine exakte Prognose, echte Workloads schwanken.

Ein häufig unterschätzter Faktor in dieser Rechnung: regelmäßige Backup-Jobs, gerade mit Proxmox Backup Server, erzeugen eigene, oft sync-lastige Schreibspitzen auf dem Quellsystem, zusätzlich zur laufenden VM-Last. Wie Sie Backup-Häufigkeit und Aufbewahrung sinnvoll gegen genau dieses Storage-Budget abwägen, behandelt unser Artikel zur 3-2-1-Backup-Strategie. Wer die PBS-Instanz selbst nicht auf eigener Hardware betreiben möchte, findet in unserem Managed Proxmox Backup Server eine gehostete Alternative, bei der genau dieses Verschleißthema auf unserer Seite liegt statt auf Ihrer eigenen SSD.

Erst konfigurieren, dann kaufen

Die folgenden Maßnahmen sind nach Aufwand und Wirkung sortiert. Keine davon ist ein Rezept ohne Nebenwirkung, lesen Sie den jeweiligen Risikohinweis, bevor Sie etwas ändern.

HA-Dienste abschalten, wenn Sie kein HA nutzen

Von Proxmox-Entwickler Lamprecht selbst als Hauptursache eines Teils der Dauerschreiblast bestätigt.

systemctl mask pve-ha-crm pve-ha-lrm watchdog-mux

Kosten/Risiko: Sie verlieren die komplette Failover-Fähigkeit des Clusters. Nur sinnvoll, wenn wirklich kein automatisches Failover geplant ist, sonst muss bei späterem HA-Bedarf wieder aktiviert werden.

volblocksize beim Anlegen neuer Zvols korrekt setzen

Auf die tatsächliche Blockgröße des Gastsystems abstimmen (meist 4K), nicht Proxmox' Default von 8K unhinterfragt übernehmen. Gemessene Wirkung siehe oben, +100 Prozent Overhead bei 8K gegenüber +25 Prozent bei 32K in einem RAIDZ1-Benchmark.

Kosten/Risiko: Nur beim Neuanlegen änderbar, bestehende Zvols müssen migriert werden (neues Zvol anlegen, Daten kopieren, altes löschen). Ein zu groß gewählter Wert kostet bei kleinen Random-Writes wiederum Platz-Overhead, die Gastsystem-Blockgröße ist der richtige Ausgangspunkt, nicht pauschal der größtmögliche Wert.

rrdcached-Flush-Intervall verlängern

# /etc/default/rrdcached
WRITE_TIMEOUT=3600

Kosten/Risiko: Gröbere Auflösung der Graphen im Webinterface. Wichtiger praktischer Hinweis aus der Recherche: Auf neueren PVE-Versionen ignoriert der systemd-Dienst diese Datei teils, ohne zusätzlichen systemd-Override wirkt die Änderung dann gar nicht, vor dem Ändern also prüfen, über welchen Mechanismus rrdcached auf Ihrer Version tatsächlich gestartet wird.

atime=off statt relatime

zfs set atime=off rpool/data

Kosten/Risiko: Sehr gering, eliminiert Metadaten-Schreiblast durch reine Lesezugriffe vollständig. Manche Software (seltene Backup-/Mail-Tools) wertet atime aus, im Zweifel relatime als Kompromiss wählen. Die konkrete GB/Tag-Ersparnis war in der Recherche nicht beziffert zu finden, Richtung ist aber sicher, Betrag ist eine Schätzung.

zram statt Swap auf ZFS

Swap auf einem ZFS-Zvol gilt offiziell als nicht unterstützt und kann zu Deadlocks und ungeplanten Neustarts führen, zram ist hier nicht nur die schreibsparende, sondern auch die technisch robustere Alternative.

Kosten/Risiko: Komplettes Deaktivieren von Swap ohne zram-Ersatz erhöht das Risiko von OOM-Kills unter Speicherdruck. Die konkrete SSD-Schreibersparnis ist strukturell plausibel, aber nicht beziffert.

Logs auslagern (log2ram, tmpfs)

Kosten/Risiko: Logs gehen bei einem Absturz oder harten Reboot verloren, genau dann, wenn sie für die Fehleranalyse am wichtigsten wären. Zusätzlich dokumentiert: ein zu klein dimensioniertes RAM-Volume kann volllaufen und das System de facto lahmlegen. Wenn Sie diesen Weg gehen, dimensionieren Sie großzügig und syncen Sie zumindest kritische Audit-Logs zusätzlich per Remote- Syslog auf ein anderes System.

Kompression: lz4 bleibt die richtige Wahl

zstd komprimiert stärker, kostet dafür spürbar mehr CPU beim Schreiben. Für das Ziel Verschleißreduktion ist der Umstieg zweitrangig, lz4 bietet das beste Geschwindigkeit-zu-Ratio-Verhältnis bei minimalem Overhead und ist bereits Proxmox-Standard. Ein Wechsel lohnt sich vor allem, wenn ausreichend CPU-Headroom vorhanden ist und die Daten gut komprimierbar sind, nicht als erster Hebel gegen Verschleiß.

ext4 statt ZFS nur für das Bootlaufwerk, als Kompromiss

Root-Partition und Logs auf ext4, ZFS gezielt nur für den VM-Storage-Pool, wo Snapshots, Checksumming und Replikation ihren Mehrwert tatsächlich ausspielen.

Kosten/Risiko: Sie verlieren Snapshots, Self-Healing und native Replikation für das Bootlaufwerk. Für ein System-Volume, das ohnehin selten sich ändert und separat gesichert wird, oft ein vertretbarer Kompromiss.

Wenn Sie doch tauschen müssen: worauf es ankommt

PLP als Ausschlusskriterium

Nach allem oben Gesagten sollte eine Ersatz- oder Zusatz-SSD für sync-write-lastige Proxmox-Workloads echte Power Loss Protection mit Kondensatorbank haben, nicht nur ein Marketing-Label. Datenblatt prüfen, nicht nur die Produktbeschreibung.

Baulänge M.2 2280 gegenüber 22110: der klassische Fehlkauf

Bei der Recherche für diesen Artikel fand sich ein Beispiel, das die Falle konkret zeigt: Die Micron 7450 PRO gibt es bei 960 GB Kapazität auf Amazon parallel in zwei Formfaktoren mit fast identischem Produktnamen, einmal als 2280 (22×80 mm, passt in die meisten Mini-PCs und Consumer-Mainboards), einmal als 22110 (22×110 mm, deutlich länger, passt in praktisch keinen Standard-M.2-Slot eines Mini-PCs). Ab 1,92 TB Kapazität gibt es diese Baureihe auf dem deutschen Markt überhaupt nur noch als 22110. Vor dem Kauf immer die exakte Baulänge im Datenblatt prüfen, nicht nur die Modellbezeichnung, und den verfügbaren Platz im eigenen Gehäuse nachmessen.

TBW und DWPD realistisch einordnen

Eine höhere TBW-Zahl ist nicht automatisch die richtige Wahl, wenn sie mit deutlich höherem Preis oder falscher Baulänge erkauft wird. Für einen typischen Homelab-Host mit moderater VM-Zahl reicht meist ein Read-Intensive-Modell mit 1 DWPD, Mixed-Use-Modelle mit höherem DWPD-Wert lohnen sich erst bei nachweislich schreiblastigen Datenbanken oder ähnlichen Workloads.

Wärmeentwicklung und Drosselung in Mini-PCs

Enterprise-M.2-SSDs sind für Dauerlast in gut belüfteten Servergehäusen ausgelegt, nicht für den engen, oft passiv gekühlten M.2-Slot eines Mini-PCs. Unter anhaltender Schreiblast drosseln sie dort thermisch, was die eigentlich gewonnene Performance wieder auffrisst. Ein zusätzlicher M.2-Kühlkörper ist bei diesen Laufwerken in einem Mini-PC eher Pflicht als Kosmetik, siehe die Empfehlung unten.

Gebrauchte Enterprise-SSDs: wann sinnvoll, worauf achten

Community-Berichte im Proxmox-Forum nennen gebrauchte Enterprise-SSDs mit PLP für teils unter 40 Euro auf dem Gebrauchtmarkt, deutlich günstiger als eine neue Consumer-SSD vergleichbarer Kapazität. Vor dem Kauf den aktuellen Wearout-Wert per SMART/nvme-cli abfragen lassen oder selbst prüfen, sobald das Laufwerk da ist, und die verbleibende TBW-Reserve gegen den eigenen erwarteten Workload rechnen. Bei seriösen Anbietern aus dem professionellen IT-Recycling ist das ein legitimer, oft unterbewerteter Weg zu echter PLP- Hardware.

Konkrete Empfehlungen

Sortiert nach Einsatzszenario, nicht als unspezifische Liste. Alle genannten Produkte wurden für diesen Artikel einzeln gegen echte, aktuell abgerufene Amazon-Daten geprüft (Titel, Bild, Preis, Lagerstatus). Bei Enterprise-SSDs konnten wir den tatsächlichen Verkäufer auf Amazon in keinem einzigen Fall zweifelsfrei bestimmen, die Angebote stammen erkennbar überwiegend aus dem Marketplace. Bei einem mehrere-hundert-Euro-Kauf ist es die Zeit wert, zusätzlich beim spezialisierten IT-Fachhandel oder -Grosshandel zu vergleichen, gerade weil einzelne der hier gefundenen Amazon-Preise spürbar über üblichem Marktniveau lagen.

Boot- und Systemlaufwerk im Einzelknoten

Werbung · Amazon-Partnerlink

Kingston DC2000B 480GB

Kingston · ca. 450 bis 550 Euro · Boot-/Systemlaufwerk, Einzelknoten

Vorteile

• Durchgängig M.2 2280, passt in praktisch jeden Mini-PC-Slot
• PCIe 4.0, deutlich schneller als die ältere DC1000B-Serie
• Echte Kondensator-PLP, kein Marketing-Label

Nachteil

• Bei Amazon meist nur über Marketplace-Händler verfügbar, Preis vor Kauf vergleichen

Kingston DC2000B 480GB bei Amazon ansehen

VM-Storage im Homelab-Cluster

Werbung · Amazon-Partnerlink

Micron 7450 PRO 960GB (2280)

Micron · ca. 280 bis 340 Euro · VM-Storage, Homelab-Cluster

Vorteile

• Hohe TBW-Reserve (1.700 TB) für dauerhafte VM-Last
• 2280-Bauform bei dieser Kapazität noch verfügbar
• PCIe-4.0-Performance

Nachteil

• Ab 1,92 TB gibt es diese Serie nur noch als 22110, nicht kompatibel mit den meisten Mini-PCs

Micron 7450 PRO 960GB (2280) bei Amazon ansehen

Produktiver Kundencluster (SATA-Backend)

Werbung · Amazon-Partnerlink

Kingston DC600M 1920GB

Kingston · ca. 1.150 bis 1.350 Euro · Produktiver Kundencluster, SATA-Backend

Vorteile

• Mixed-Use-Ausrichtung, höhere Schreiblast-Reserve als Read-Intensive-Modelle
• 3.504 TB TBW bzw. 1 DWPD über 5 Jahre
• 2,5-Zoll-SATA, passt in praktisch jedes Server-/NAS-Chassis

Nachteil

• Deutlich teurer als eine Consumer-SATA-SSD, nur bei echtem Mixed-Use-Bedarf sinnvoll

Kingston DC600M 1920GB bei Amazon ansehen

Der Sonderfall Mini-PC mit nur einem M.2-Slot

Hier zählt die Baulänge zuerst: nur 2280-Modelle kommen infrage, siehe die Warnung oben. Kingstons DC2000B- und DC1000B-Serien sind über alle geprüften Kapazitäten hinweg durchgängig 2280 gebaut, damit eine der wenigen Enterprise-Linien, die zuverlässig in einen Mini-PC passt. Dazu einen Kühlkörper einplanen, siehe unten.

Werbung · Amazon-Partnerlink

GRAUGEAR M.2-Kühler mit PWM-Lüfter

GRAUGEAR · ca. 20 bis 28 Euro · Enterprise-M.2 im Mini-PC vor thermischer Drosselung schützen

Vorteile

• Aktiver PWM-Lüfter plus Kupfer-Heatpipe, wirksamer als reine Passivkühler
• Kompakt genug für die meisten Mini-PC-Gehäuse

Nachteil

• Zusätzliches bewegliches Teil, leichtes Betriebsgeräusch

GRAUGEAR M.2-Kühler mit PWM-Lüfter bei Amazon ansehen

Die günstigere Alternative, über die niemand spricht

Nicht jedes Setup braucht sofort eine neue Enterprise-SSD. Der eigentliche Grund, warum PLP so wirksam ist, liegt darin, dass sie das Risiko eines Stromausfalls mitten in einem sync-Write absichert. Eine ordentliche USV mit sauberem Shutdown-Skript adressiert genau dieses Risiko auf einer anderen Ebene: Sie verhindert den plötzlichen Stromverlust im Normalfall überhaupt, statt ihn nur nachträglich abzufedern. Für ein Single-Node-Homelab mit ohnehin schon vernünftig konfiguriertem ZFS (korrekte volblocksize, HA aus, wenn nicht gebraucht) ist eine 100 bis 150 Euro teure USV oft die ehrlichere erste Investition als eine 300-Euro- SSD, insbesondere weil sie zusätzlich Hardwareschäden durch harte Stromausfälle generell reduziert, nicht nur SSD-Verschleiß.

Wo das nicht reicht: Eine USV schützt nicht vor Kernel-Panics, OOM-Kills oder Proxmox- Abstürzen mitten im Betrieb, nur vor Stromausfall. In einem Produktivcluster mit mehreren Knoten und echtem Failover-Bedarf ersetzt sie PLP nicht, sondern ergänzt sie bestenfalls.

Werbung · Amazon-Partnerlink

Eaton 5S700I USV

Eaton · ca. 130 bis 160 Euro · Single-Node-Homelab als Ergänzung oder Alternative zur teuren SSD

Vorteile

• Line-Interactive mit AVR, gleicht Unterspannung ohne Akku-Einsatz aus
• USB-Anbindung für ein sauberes automatisches Shutdown-Skript

Nachteil

• Schützt nicht vor Software-Abstürzen oder OOM-Kills, nur vor Stromausfall

Eaton 5S700I USV bei Amazon ansehen

Häufige Fragen

Wie schnell nutzt sich eine Consumer-SSD unter Proxmox wirklich ab?
Stark variabel: von 2 bis 3 Prozent Wearout nach 4 bis 6 Monaten (dokumentierte Samsung-980-Pro-Fälle) bis zu Extremwerten bei Fehlkonfiguration wie verschachteltem ZFS-auf-ZFS. Entscheidend sind Workload, volblocksize und ob HA-Dienste aktiv sind, eine pauschale Zahl wäre unseriös.

Was bedeutet Power Loss Protection wirklich?
Echte PLP ist eine Kondensatorbank plus Firmware, die den DRAM-Cache bei Stromausfall aktiv ins NAND sichert. Viele so beworbene Consumer-Laufwerke schützen dagegen nur die FTL-Mapping-Tabelle, nicht die Nutzdaten im Cache.

Sollte ich zfs set sync=disabled setzen?
Nein, siehe die Warnung weiter oben. Das hebelt den ZIL-Schutz aus und riskiert Datenverlust bei Absturz, vertretbar höchstens für komplett verzichtbare Scratch-Daten.

Was schreibt Proxmox eigentlich ständig, auch ohne laufende VM?
Vor allem pmxcfs/config.db, laut Proxmox-Entwickler Thomas Lamprecht hauptsächlich durch periodische HA-Status-Updates, dazu pvestatd und rrdcached. Gemessen wurden über 10 Schreibvorgänge pro Sekunde allein durch pmxcfs.

Muss ich zwingend eine Enterprise-SSD mit PLP kaufen?
Nicht zwingend, aber PLP ist der wirksamste Einzelhebel bei sync-lastigen Workloads, rund Faktor 130 bei der sync-Schreibrate in unabhängigen Benchmarks. Gebrauchte Enterprise-SSDs mit PLP sind oft günstiger als eine große neue Consumer-SSD.

Wie lese ich Data Units Written richtig?
Wert × 512.000 Byte ergibt die tatsächlich geschriebene Datenmenge. Percentage Used ist eine Herstellerschätzung des verbrauchten Endurance-Budgets, kein zwingender Defekt bei 100 Prozent.

Verändert eine falsche volblocksize die Lebensdauer wirklich messbar?
Ja, deutlich: 8K statt 64K volblocksize kostete in einem Benchmark bis zu 107 Prozent mehr Overhead, ein Nutzer maß in einer Zvol-Kette einen Amplifikationsfaktor von rund 10×.

Ist die Wearout-Prozentanzeige in Proxmox immer korrekt?
Nein, sie basiert auf herstellerspezifischen SMART-Attributen. Ein dokumentierter Fall zeigte einen scheinbaren Sprung von 0 auf 98 Prozent, der sich als invertiertes WD-Attribut herausstellte. Bei alarmierenden Werten zusätzlich nvme smart-log gegenprüfen.

Fazit

Der Verschleiß kommt nicht von ZFS allein und nicht von Proxmox allein, sondern von der Kombination aus konstanter kleiner synchroner Schreiblast und einem Laufwerk, das jede einzelne Transaktion einzeln ins NAND programmieren muss. Wer die kostenlosen Hebel zieht und bei einer Neuanschaffung konsequent auf echte Power Loss Protection statt auf ein Marketing-Label achtet, löst beide Hälften des Problems, nicht nur die teure.

Preise und Verfügbarkeit können sich jederzeit ändern. Maßgeblich ist der zum Zeitpunkt des Kaufs auf amazon.de angezeigte Preis. Stand der Recherche: 21.08.2026.

Bildnachweis: Aufmacherbild und PLP-Vergleichsfoto KI-generiert (Higgsfield), Schreibpfad-Diagramm eigene Grafik. Details in BILDQUELLEN.md.

Als Amazon-Partner verdienen wir an qualifizierten Verkäufen.