SSD-Gesundheit: SMART unter Windows und Linux

Deine SSD schickt dir keine Postkarte, bevor sie ausfällt. Sie führt aber ein paar Zähler, und sie zu lesen dauert fünf Minuten. Verwechsle nur den Rauchmelder nicht mit der Wahrsagerin.

Kurzantwort

SSD-Gesundheit: Wie liest du SMART unter Windows und Linux? Sichere zuerst, lies dann die Zähler des Laufwerks. Unter Windows zeigt die Einstellungen-App sie nur für NVMe-Laufwerke [8]; PowerShell zeigt ein paar mehr [9][10]; smartctl aus den smartmontools liest den vollständigen Bericht unter Windows und Linux [1]; unter Linux liest nvme-cli das NVMe-Protokoll [6]. Bei einem NVMe-Laufwerk schaust du zuerst auf vier Felder: Critical Warning, Available Spare, Percentage Used und Media and Data Integrity Errors [3][4]. Ein sauberer Bericht ist keine Garantie, und eine hohe Zahl ist kein Todesdatum. Der NVMe-Standard sagt, dass ein Percentage Used von 100 nicht unbedingt einen Ausfall anzeigt [3][4]; und Googles Feldstudien fanden Laufwerke, die ohne SMART-Warnung ausfielen [15], sowie Flash-Laufwerke mit häufigen nicht korrigierbaren Fehlern [16]. Unsere Einschätzung: Behandle SMART wie einen Rauchmelder, protokolliere es monatlich und überlasse den eigentlichen Schutz dem Backup. Aus einem einzelnen Wert leiten wir keine Lebensdauer ab.

So funktioniert’s

1. Erst sichern, dann testen. SMART zu lesen ist eine leichte Abfrage. Ein langer Selbsttest oder ein Rettungsversuch ist es nicht. Der Autor von CrystalDiskInfo sagt es klar: Zeigt das Werkzeug „Caution“ oder „Bad“, sichere deine wichtigen Daten auf einem anderen Speichermedium, bevor du die Ursache untersuchst [13]. Dieselbe Seite sagt, ein „Caution“ heiße nicht, dass das Laufwerk heute aufhört, gebe aber auch keine Garantie für Monate oder Jahre [13]. Unsere Einschätzung: Die Reihenfolge lautet Backup, Lesen, Protokollieren und erst dann Selbsttest. Wie du ein Backup anlegst, das sich wiederherstellen lässt, steht auf unserer Seite zum 3-2-1-Backup.
2. Was SMART ist. Self-Monitoring, Analysis and Reporting Technology ist die Menge der Zähler, die ein Laufwerk über sich selbst führt. SATA-Laufwerke melden nummerierte Attribute mit einem normierten VALUE, einem WORST-Wert, einem THRESHOLD und einem RAW-Wert; NVMe-Laufwerke melden eine einheitlich definierte Seite, das SMART/Health-Information-Log (Log-Kennung 02h) [3][4]. Was ein SATA-Attribut bedeutet, bestimmt der Hersteller. smartctl sagt das selbst: Ein Attribut vom Typ „Pre-fail“ heißt nicht, dass die Platte bald ausfällt; es zählt erst, wenn der aktuelle normierte Wert auf oder unter dem Schwellenwert liegt, was smartctl dann mit FAILING_NOW kennzeichnet (oder mit In_the_past, wenn nur der schlechteste jemals gemessene Wert dort lag) [1]. CrystalDiskInfo zeigt, wie herstellerspezifisch das ist: Je nach Controller liest es Microns Attribut 0xCA, Intels 0xE8, SandForces 0xE7 oder Samsungs 0xB4 als „Lebensdauer“-Bezug [12].

Die NVMe-Felder, auf die es ankommt

Sie stammen aus der Protokollseite, die der NVMe-Standard festlegt [3]; die Beschreibungen folgen der libnvme-Dokumentation, die den Standard zitiert [4][5].

SATA-SSDs

Die Windows-Einstellungen überwachen nur NVMe-SSDs, keine SATA-SSDs und keine Festplatten [8]. Für eine SATA-SSD nimmst du smartctl oder ein Werkzeug wie CrystalDiskInfo. CrystalDiskInfo stuft eine SSD bei einer Restlebensdauer von 10 Prozent oder weniger für die Controller-Familien, die es kennt, als „Caution“ ein [12]; sein Autor weist darauf hin, dass es nicht jedes Laufwerk unterstützt und manche falsch beurteilen kann [13]. smartctl meldet seinen Exit-Status als Bitmaske: Bit 3 heißt, die SMART-Statusprüfung lieferte „DISK FAILING“, Bit 4 heißt Pre-fail-Attribute auf oder unter der Schwelle, Bit 6 und Bit 7 heißen, dass das Fehlerprotokoll oder das Selbsttest-Protokoll Fehlereinträge enthält [1]. Die Man-Page definiert diese Bits für ATA-Platten; bei anderen Laufwerkstypen schau in die Seite deiner Version. Lies Bit 6 und 7 als „schau in die Protokolle“, nicht als „das Laufwerk ist tot“.

Windows: drei Wege

Erstens die Einstellungen-App. Öffne Start > Einstellungen > System > Speicher > Erweiterte Speichereinstellungen > Datenträger und Volumes und dort die Eigenschaften des Laufwerks [8]. (Wir geben den Menüpfad nach Microsofts englischer Seite wieder; die deutschen Menünamen können leicht abweichen.) Bei NVMe-Laufwerken zeigt Windows kritische Warnungen, die geschätzte Restlebensdauer, die verfügbare Reserve und die Temperatur [8]. Zweitens PowerShell. Die erste Zeile listet deine Laufwerke mit Bus-Typ und Zustand, die zweite liest die Zuverlässigkeitszähler [9][10][11]:

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType, HealthStatus, OperationalStatus, Size
Get-PhysicalDisk | Get-StorageReliabilityCounter | Format-List DeviceId, Temperature, Wear, PowerOnHours, ReadErrorsTotal, ReadErrorsUncorrected, WriteErrorsTotal, WriteErrorsUncorrected

Nicht jedes Laufwerk, jeder Treiber und jede USB-Bridge füllt jedes Feld. Microsofts eigene Beispielausgabe zeigt einen leeren Wear-Wert [9]; lies also einen leeren Wert als „nicht gemeldet“, niemals als null. HealthStatus ist die Zusammenfassung von Windows und kein Ersatz für den vollständigen Bericht (unsere Einschätzung). Drittens smartctl. Installiere die smartmontools, öffne ein Terminal mit Administratorrechten (unsere Einschätzung: Windows verlangt das meist) und lass smartctl die Geräte auflisten; nimm den Namen, den es für dein Laufwerk ausgibt, und kopiere keinen Namen von einem anderen Rechner [1]:

smartctl --scan
smartctl -a <Gerätename, wie ihn --scan ausgibt>

Bei NVMe entspricht -a den Optionen -H -i -c -A -l error -l selftest [1].

Linux: drei Wege

Finde zuerst das Laufwerk. Lies es dann mit smartctl, mit nvme-cli oder als JSON für ein Protokoll [1][6][17][18]:

lsblk -d -o NAME,MODEL,SERIAL,SIZE,TRAN
sudo smartctl -a /dev/nvme0
sudo nvme list
sudo nvme log smart /dev/nvme0
sudo nvme log error /dev/nvme0

sudo nvme smart-log /dev/nvme0 und sudo nvme error-log /dev/nvme0 sind die Namen vor nvme-cli 3.0; die alten Befehle laufen in 3.0 weiter, geben eine Veraltet-Warnung aus und können in einer künftigen Version verschwinden [6][7]. Deine Version prüfst du mit nvme version. Bei einer SATA-SSD heißt das Gerät meist /dev/sda (prüfe die lsblk-Ausgabe), und sudo smartctl -a /dev/sda ist derselbe Aufruf. smartctl kann auch JSON liefern: smartctl -j -A /dev/nvme0 gibt die NVMe-Werte unter nvme_smart_health_information_log aus, zum Beispiel percentage_used, data_units_written, media_errors, available_spare und critical_warning [18].

USB-Gehäuse und -Adapter

Eine USB-Bridge sitzt zwischen dir und dem Laufwerk und kann die SMART-Befehle blockieren. Für SATA-SSDs legt der Standard SCSI/ATA Translation einen herstellerunabhängigen Durchreichebefehl fest, den viele USB-SATA-Bridges unterstützen und den smartctl mit -d sat nutzt [1][2]. Für NVMe schrieb ein smartmontools-Entwickler 2018, es gebe kein herstellerunabhängiges Gegenstück [2]; smartctl hat deshalb bridge-spezifische Typen wie sntasmedia, sntjmicron und sntrealtek und seit smartctl 7.5 ein experimentelles Suffix /sat, das bei kombinierten M.2-Adaptern auf SATA zurückfällt [1]. Nimm einen Typ nur, wenn das Scan-Ergebnis oder die Dokumentation des Adapters ihn stützt, und sei vorsichtig mit usbjmicron,x: Die Man-Page warnt vor E/A-Fehlern und einem sich trennenden Laufwerk, wenn die Bridge es nicht unterstützt [1]. Schlägt eine Abfrage fehl, kann der Adapter die Ursache sein, und der Fehlschlag allein zeigt keine defekte SSD (unsere Einschätzung). Im Zweifel liest du das Laufwerk direkt in einem Rechner.

Selbsttests

smartctl -t short und smartctl -t long starten die eigenen Tests des Laufwerks, und smartctl -l selftest gibt die Ergebnisse aus [1]. Bei NVMe-Laufwerken kennzeichnet die Man-Page -t short und -t long seit smartctl 7.4 als experimentelle Funktion, und das Laufwerk muss sie unterstützen [1]. Auch ein bestandener Selbsttest ist keine Garantie. Führe ihn nach dem Backup aus, nicht anstelle davon.

Von Zählern zu Terabyte

Data Units Written zählt Tausender-Einheiten zu je 512 Byte, eine Einheit steht also für 512.000 Byte [14]. Geschriebene Terabyte (dezimal) = Data Units Written × 512.000 ÷ 10¹². Das TBW im Datenblatt ist die Herstellerangabe, wie viele Host-Schreibzugriffe das Laufwerk vor dem Verschleiß verkraftet; der Write Amplification Factor ist NAND-Schreibvorgänge geteilt durch Host-Schreibvorgänge, und DWPD ist TBW geteilt durch 365, die Garantiejahre und die Kapazität [14]. Wegen der Schreibverstärkung müssen das Percentage Used des Laufwerks und dein Anteil am Datenblatt-TBW nicht übereinstimmen (unsere Einschätzung). Nimm TBW als Garantiegröße und Percentage Used als Schätzung des Laufwerks. Keins von beiden ist ein Countdown.

Protokollieren: eine Zeile im Monat

Ein einzelner Wert sagt wenig, eine Reihe zeigt eine Richtung. Diese Zeile hängt eine Zeile an eine CSV-Datei an (führe sie mit den für smartctl nötigen Rechten aus):

smartctl -j -A /dev/nvme0 | jq -r '.nvme_smart_health_information_log | [(now|todate), .percentage_used, .data_units_written, .media_errors, .available_spare, .critical_warning, .power_on_hours] | @csv' >> ssd-log.csv

Den jq-Filter haben wir an einem selbst gebauten Muster getestet, nicht an einem echten Laufwerk, und die Schlüsselnamen folgen dem Quelltext des smartctl_exporter [18]. Googles Flash-Studie fand, dass frühere Fehler verschiedener Art spätere nicht korrigierbare Fehler vorhersagen [16]; deshalb wiegt eine steigende Fehlerzahl schwerer als ein einzelner Wert (unsere Einschätzung).

Was du mit den Zahlen tust

Ein Szenario, keine eigenen Daten

Stell dir ein NVMe-Laufwerk vor, das 3.120 Betriebsstunden gelaufen ist und diese Werte meldet (für dieses Beispiel erfunden): Critical Warning 0, Available Spare 100 Prozent bei einer Schwelle von 10 Prozent, Percentage Used 2, Media and Data Integrity Errors 0, Error Information Log Entries 0, Unsafe Shutdowns 14, Data Units Written 7.935.401 und Data Units Read 10.584.293. Die Rechnung: 7.935.401 × 512.000 Byte ≈ 4,06 TB geschrieben und 10.584.293 × 512.000 Byte ≈ 5,42 TB gelesen (dezimale Terabyte). Stünde im Datenblatt 600 TBW (eine erfundene Zahl), wären 4,06 TB deutlich weniger als ein Prozent dieser Angabe, während das Laufwerk selbst 2 Prozent Verbrauch meldet: ein Abstand, wie man ihn von der eigenen Schätzung des Laufwerks und der Schreibverstärkung erwartet, und kein Grund zur Sorge. Die 14 Unsafe Shutdowns sind einen Blick auf Strom und Abschaltgewohnheit wert. Der Plan: sichern, Datum und Werte ins Protokoll schreiben, in einem Monat erneut lesen. Aus diesem einen Wert entsteht keine Prognose der Restlebensdauer.

Prüfliste

• Sichere deine Daten, bevor du einen Selbsttest startest oder den Hersteller kontaktierst.
• Stelle fest, welches Laufwerk du vor dir hast und an welchem Bus: NVMe oder SATA, intern oder hinter USB.
• Lies den Bericht mit smartctl und nimm Einstellungen oder nvme-cli als zweite Sicht.
• Prüfe zuerst Critical Warning, Available Spare, Percentage Used und Media and Data Integrity Errors.
• Rechne Data Units Written in Terabyte um und notiere Zahl und Datum.
• Behandle leere Werte als „nicht gemeldet“, niemals als null.
• Nutze -d sat oder den Bridge-Typ nur, wenn Scan oder Adapter-Dokumentation ihn stützen.
• Starte einen Selbsttest erst nach dem Backup und lies ihn mit -l selftest.
• Protokolliere die Kernwerte einmal im Monat und vergleiche mit der letzten Zeile.
• Ersetze das Laufwerk, wenn eine Warnung, ein Medienfehler oder eine steigende Fehlerzahl auftaucht, nicht erst, wenn du ein Datum geraten hast.

Passt dazu: NVMe-SSDs verstehen; 3-2-1-Backup und Wiederherstellungstest; Backblaze Drive Stats richtig lesen; Offsite-Backup fürs Homelab: die dritte Kopie; S.M.A.R.T.: Laufwerksgesundheit; TRIM für SSDs; TBW: Schreibmenge einer SSD. Unsere Einschätzung: Auch ein Laufwerk mit sauberen SMART-Werten fällt manchmal aus; entscheidend ist daher, ob eine Wiederherstellung aus deinem Backup funktioniert. Preise nennen wir hier nicht.