Stirbt meine NVMe? Welcher Nachfolger?

x.treme

Captain
Registriert
Sep. 2008
Beiträge
3.240
Hallo zusammen,

ich nutze in meinem HP MiniPC eine 1TB Transcend TS1TMTE220S für Proxmox

Der Backup einer meiner virtuellen Maschinen führte immer reproduzierbar zu einem Systemabsturz aufgrund EA-Errors.

In den Logs findet sich folgender Fehler:
Code:
nvme0n1: I/O Cmd(0x2) @ LBA 371154584, 136 blocks, I/O Error (sct 0x2 / sc 0x81) MORE
kernel: critical medium error, dev nvme0n1, sector 371154584 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 2

SMART gibt zwar "Passed" aus, aber es sind "Media and Data Integrity Errors" im Log.
1705582552830.png


Ich habe die betroffende VM gelöscht und durch ein Backup ersetzt - jetzt läuft wieder alles.
Aber kann ich die NVME überhaupt noch guten Gewissens verwenden?

Und falls nicht - was wäre eine alternative NVMe, die eine längere Lebensdauer (auch bei den ggf. problematischen Temperaturen in einem MiniPC) aufweist?
 
Moderne TLC SSDs haben eine ausreichende Lebensdauer. Deine TS1TMTE220S hat 2.2 PBW, sollte also relativ lange halten. Die Fehler müssen also eine andere Ursache haben.

Laut Screenshot wurde die SSD nur in knapp 63% aller Vorkomnisse sauber ausgeschaltet. 4k Betriebsstunden sind ziemlich wenig und die 8TBW entsprechen nichtmal 1% der SSD Lebensdauer. Außerdem hat deine SSD 59 mal wegen Temperaturproblemen abgeschaltet.

Du solltest erstmal die Kühlung kontrollieren.
Bei Bedarf einen Kühler drauf schrauben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: x.treme, H3llF15H und kolege
Transcend ist die womöglich schlechteste Firma die Speichergeräte herstellt.
 
Simanova schrieb:
Moderne TLC SSDs haben eine ausreichende Lebensdauer. Deine TS1TMTE220S hat 2.2 PBW, sollte also relativ lange halten. Die Fehler müssen also eine andere Ursache haben. Du solltest erstmal die Kühlung kontrollieren.
Bei Bedarf einen Kühler drauf schrauben.

Jep, hatte mich bewusst für die NVMe entschieden wegen der hohen PBW.

Kühlung ist leider ein wenig problematisch, der HP ProDesk 400 G5 ist halt ein MiniPC und besitzt nur einen CPU-Kühler, keine Möglichkeit weitere Kühler zu nutzen.

Jetzt im Winter passen aber die Temperaturen, das ist dann eher im Sommer bei > 30°C Zimmertemperatur problematisch.

Garantie wäre kein Problem, würde ich aber nur machen wenn aufgrund der SMART-Werte dringend erforderlich. Kostet halt nen guten Tag wieder Proxmox komplett neu einzurichten ...
 
Habe kein Image vom Host ( ich mache ein tägliches externes Backup der VMs/Container, der Host selber ist ja relativ generisch ). Ein solches jetzt zu machen wo die NVMe ggf. EA-Errors beim Lesen erzeugt ist vlt. nicht das sinnvollste ... dann lieber gleich frisch aufsetzen.
 
Ich würde mit einem Programm mal einen Scan über die gesamte Kapazität machen. Es gibt ja auch SMART-Diagnosen, die einen kompletten Scan machen...zumindest bei SATA-SSDs, ich hoffe auch bei M.2-SSDs.

SSDs (und HDDs) haben Reserve-Sektoren und laut deinem SMART-Auszug ist die Reserve noch bei 100%. Es überrascht mich, dass die noch nicht benutzt werden. Es sei denn die "Media and Data Integrity Errors" beziehen sich auch auf andere Dinge, nicht nur eindeutige Sektoren-Defekte. Aber das ist jetzt nur geraten, ich habe keine/kaum Ahnung davon.
 
So wie es aussieht, hast du da eine Consumer SSD. Das ist grundsätzlich nichts schlechtes, aber Proxmox ist sehr schreiblastig, insbesondere wenn du das Logging nicht reduzierst. Das ganze ist für Produktivsysteme natürlich nur eingeschränkt zu empfehlen, weil das Logging im Fehlerfall wichtig ist. Ich mache es aber so wie in dem verlinkten Post beschrieben:

Bash:
systemctl disable --now corosync pve-ha-lrm pve-ha-crm
JOURNALD_CONF="/etc/systemd/journald.conf"
grep -q 'Storage=volatile' "$JOURNALD_CONF" || cat << 'EOF' >> "$JOURNALD_CONF"
Storage=volatile
ForwardToSyslog=no
EOF

Du könntest als "Nachfolger" eine Enterprise SSD verwenden (sowas wie die Samsung PM983 oder sogar Intel Optane), aber die kosten ne Menge Geld - statistisch gesehen lohnt sich das eventuell, allerdings musst du beachten, dass der Formfaktor der PM983 z.B. LÄNGER ist, als bei normalen SSDs. Das muss vom Mainboard unterstützt werden. Falls das nicht passt, kann ich eine WD SN850x empfehlen, die läuft bei mir bisher ziemlich stabil, ist schnell und ist ähnlich wie eine Samsung 980 Pro oder Samsung 990 Pro. Seit diesem Firmware-Bug vertraue ich Samsung nicht mehr so wie früher.

Ich hab übrigens noch eine nagelneue 2TB Samsung Enterprise SSD hier liegen, die bei mir nicht gepasst hat. Wenn die jemand braucht, gerne per PM melden, ich würde sie günstig abgeben (150 Euro VHB).

Für die bessere Kühlung könntest du einen "be quiet! MC1 Pro" verwenden, wenn er ins Gehäuse passt. Die sind passiv und ganz gut. Ob du damit in so einem engen Gehäuse aber ne deutliche Verbesserung erzielst, ist fraglich

Wenn du ZFS verwendest, kannst du Backups machen, in dem du die Datasets recursiv über SSH an einen anderen Host oder an ein externes Laufwerk sendest. Ich habe z.B. einfach den Proxmox installer auf einem anderen Rechner benutzt, um eine Festplatte mit bootfähigem Root-Pool auszustatten, dann alle Datasets weggeworfen bis auf den rpool, einmal ein volles Backup gemacht und sende jetzt die Backups inkrementell über SSH dahin. Man kann das ganze auch lokal machen, dafür wäre ein externes USB NVMe-Gehäuse nützlich. Das hier unterstützt alle Arten von M2 SSDs (sogar die langen Enterprise Dinger), ist aber teurer als andere.

Im Fehlerfall nehme ich den Installer, mache den auf eine "frische" SSD und schiebe rückwärts die ZFS-Daten einfach wieder über SSH zurück. Wie das genau geht, schreibe ich jetzt mal nicht auf, weil der zfs destroy ist nicht ganz ohne, aber ich schaue mal nach, wo ich das script habe dann kann ich es auszugsweise bei Bedarf zusenden. Ich verwende übrigens für mein Proxmox-System auch die ZFS verschlüsselung, weil ich paranoid bin. Das ist aber nicht ohne. Wenn dich das auch interessiert, einfach mal anmerken, dann poste ich, wie ich das root-Dataset inkl. data und var-lib-vz aes verschlüssle.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: x.treme
@sandreas Ja die Schreiblast von Proxmox kenne ich nur zu gut, hatte bei meiner vorherigen SSD einen extremen Wearout.
Habe diesmal eigene Services wie ha etc. deaktiviert, seit dem ist es völlig im Rahmen.
Der Wearout ist gerade bei gerundeten 0% nach einem halben Jahr bei nur 1,6TB geschriebenen Daten.

Ich nutze Full-Disk-Encryption mit LUKS und Dropbear ... das habe ich damals nicht mit ZFS zum laufen gebracht. Sollte ich den Server neu aufsetzen, schaue ich mir das nochmal an, ZFS snapshots wäre auch für den nahtloseren Backup der LXC von Vorteil ...
 
x.treme schrieb:
Ich nutze Full-Disk-Encryption mit LUKS und Dropbear ... das habe ich damals nicht mit ZFS zum laufen gebracht. Sollte ich den Server neu aufsetzen, schaue ich mir das nochmal an, ZFS snapshots wäre auch für den nahtloseren Backup der LXC von Vorteil ...
Das ist tatsächlich auch nicht ganz so ohne. Ich habe das ganze mal auf Hardwareluxx gepostet, der Beitrag ist aber schon älter und funktioniert mit Proxmox 8.1.3 wahrscheinlich nicht mehr 100%ig. Als Leitfaden taugt er aber dennoch.

Proxmox 8 hat auch ein var-lib-vz dataset (/var/lib/vz), welches man zusätzlich zu `/rpool/data`verschlüsseln muss, damit die VM und LXC Backups auch verschlüsselt werden.

Aktuell arbeite ich an ein paar Blog-Artikeln darüber, aber das wird noch ne Menge Zeit in Anspruch nehmen. Darin beschreibe ich auch, wie man Docker in einem unprivileged LXC laufen lassen und das auf eine user-id im host mappen kann. Soll man zwar eigentlich nicht machen, aber das ist tatsächlich sehr stabil und äußerst bequem mit Portainer und NginX Proxy Manager.

Hier mal ein paar ZFS-Befehle, die ich für mein Backup verwende. Wichtig: Beim recv muss der pool LEER sein, das heißt keine Snapshots oder Datasets enthalten. Man kann dafür die bestehenden Datasets mit destroy löschen, die Befehle würde ich aber nicht mit dazuschreiben, weil die auf dem falschen Volume alles wegwerfen. Das ist etwas heikel.

Zusätzlich ist das Paket apt-get install zfs-auto-snapshot super, das automatisiert in zeitabständen Snapshots erstellt und veraltete wieder zerstört um Platz zu schaffen. Schützt ganz gut vor Ransomware, wenn man es rechtzeitig merkt und die Ransomware keinen root Zugriff bekommt.

Bash:
# aktuellen snapshot vom hauptpool erstellen (rekursiv)
zfs snapshot -r rpool@backup-2024-01-19

# diesen Snapshot an eine externe Festplatte mit einem pool rpoolbak senden
# -R - rekursiv
# --raw - 1:1 Rohdaten senden (funktioniert auch bei verschlüsselten pools)
# | pv - pv ist ein tool was die bandbreite misst, so zeigt er den Fotschritt an, das kann man auch weglassen
#
zfs send -R --raw rpool@backup-2024-01-19 | pv | zfs recv -Fdu rpoolbak

# zfs rpool komplett über ssh wieder herstellen
zfs send -R --raw rpoolbak@backup-2024-01-19 | pv | ssh myhost zfs recv -Fdu rpool

Weitere nützliche Befehle:
Bash:
# verfügbare pools anzeigen
zpool import

# pool importieren ohne die Datasets zu mounten
zpool import -N rpool

# pool importieren (mit -f auch wenn er nicht richtig exportiert wurde)
zpool import -f rpoolbak

# pool exportieren (sollte man nach dem import immer machen)
zpool export rpool

# datasets auflisten (inkl. mountpoint)
zfs list

# snapshots und deren Speicherbedarf listen (nützlich zum Platz schaffen)
 zfs get written

# snapshots auflisten
zfs list -t snapshot

# key von verschlüsseltem pool laden
zfs load-key rpool/ROOT

# mountpoint festlegen / ändern
zfs set mountpoint=/mnt/pve-1 rpool/ROOT/pve-1

# dataset mounten
zfs mount rpool/ROOT/pve-1

# snapshot inkrementell übertragen (nur die geänderten daten)
 zfs send -i rpool@backup-2024-01-01 rpool@backup-2024-01-19 | ssh backuphost zfs recv rpoolbak
 
  • Gefällt mir
Reaktionen: x.treme
Zurück
Oben