Warum gibt diese SSD inkonsistente Daten zurück, warum stimmt die Backup-Image-Datei nicht mit der Prüfsumme überein?

Hier geht es um die SSD in einem Notebook. Es scheint, dass die SSD bereits defekt ist und möglicherweise sogar Daten beschädigt. Es scheint, dass jedes Mal, wenn auf ihn zugegriffen wird, andere Daten zurückgegeben werden (Einzelheiten siehe unten). Welche Tools können verwendet werden, um diesen Verdacht zu bestätigen?

Wenn eine HDD langsam zu sterben beginnt, gibt es normalerweise eine eindeutige Anzeige in der SMART-Ausgabe. Ein grafisches Werkzeug (wie beispielsweise) gsmartcontrolwürde einen bestimmten Wert rot hervorheben und ein ähnlicher Dienst hat smartdmöglicherweise bereits eine Warnung ausgegeben . Zu diesem Zeitpunkt hat der Benutzer möglicherweise noch etwas Zeit, um eine Sicherung zu erstellen, bevor das Laufwerk die Daten beschädigt. Wenn das Laufwerk bereits Daten beschädigt hat, könnten einige Dateien in diesem Backup beschädigt werden.

Es scheint, dass es keine eindeutige Warnung in der SMART-Ausgabe für diese SSD gibt. Es wurden keine Kernel-Fehler in dmesg usw. protokolliert (auf der anderen Seite hat ecryptfs Fehler protokolliert). Mit anderen Worten, es wurde nur durch Zufall entdeckt, dass diese SSD bereits so schlecht ist, dass sie Daten beschädigt, selbst wenn sie nicht verwendet wird.
Nachdem ich ein Backup (1: 1 dd-Image) dieser SSD (sda) erstellt hatte, stellte ich fest, dass die Prüfsumme der Image-Datei nicht mit der Prüfsumme der SSD übereinstimmt. Natürlich befand sich dies in einem Live-System, sodass die SSD nicht bereitgestellt wurde, was bedeutet, dass sich der Inhalt während des Sicherungsvorgangs nicht geändert haben konnte.

So habe ich die Sicherungskopie erstellt. Unter "BUTTER" habe ich ein externes Laufwerk gemountet, das mit BTRFS formatiert ist, so dass ich Datenfehler feststellen kann, falls das Sicherungslaufwerk ebenfalls schlecht ist (im Gegensatz zu den meisten anderen Dateisystemen enthält BTRFS Prüfsummen).

[root@localhost mnt]# time dd if=/dev/sda of=BUTTER/SSD.dd.img bs=400M && echo OK 610+1 records in 610+1 records out 256060514304 bytes (256 GB, 238 GiB) copied, 5188.27 s, 49.4 MB/s  real 86m28.726s user 0m0.008s sys 7m3.597s OK 

Ich habe eine MD5-Prüfsumme der Image-Datei und eine weitere der SDDs erstellt, die nicht übereinstimmten. Nachdem ich diesen Vorgang wiederholt hatte, stellte ich fest, dass die MD5-Prüfsumme der SSD jedes Mal anders ist .

[root@localhost mnt]# time dd if=/dev/sda bs=400M | md5sum >/tmp/MD5-again  610+1 records in 610+1 records out 256060514304 bytes (256 GB, 238 GiB) copied, 1059.87 s, 242 MB/s  real 17m39.904s user 8m21.708s sys 3m58.466s [root@localhost mnt]# cat /tmp/MD5-again 24e71715359158f3ab38e748af93718c - [root@localhost mnt]# time dd if=/dev/sda bs=400M | md5sum >>/tmp/MD5-again 610+1 records in 610+1 records out 256060514304 bytes (256 GB, 238 GiB) copied, 1073.7 s, 238 MB/s  real 17m53.735s user 8m28.494s sys 4m23.993s [root@localhost mnt]# cat /tmp/MD5-again 24e71715359158f3ab38e748af93718c - 569d517626c1b7394acca0c4020c99bc - 

Die SSD wurde während dieses Vorgangs an keiner Stelle montiert.

# mount | grep -c sda 0 

Ich habe einen SMART-Test durchgeführt, der nichts gefunden hat. Es wird kein SMART-Fehler protokolliert.
SMART-Attribute:

Gerätemodell: SanDisk SD8TN8U256G1001

[root@localhost mnt]# smartctl -A /dev/sda smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.16.3-301.fc28.x86_64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org  === START OF READ SMART DATA SECTION === SMART Attributes Data Structure revision number: 4 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0032 100 100 --- Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 --- Old_age Always - 3173 12 Power_Cycle_Count 0x0032 100 100 --- Old_age Always - 1117 170 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 0 171 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 0 172 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 0 173 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 37 174 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 41 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 --- Old_age Always - 0 180 Unused_Rsvd_Blk_Cnt_Tot 0x0033 100 100 010 Pre-fail Always - 100 184 End-to-End_Error 0x0033 100 100 097 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 --- Old_age Always - 0 194 Temperature_Celsius 0x0022 056 062 --- Old_age Always - 44 (Min/Max 13/62) 199 UDMA_CRC_Error_Count 0x0032 100 100 --- Old_age Always - 0 233 Media_Wearout_Indicator 0x0033 093 100 001 Pre-fail Always - 15484248 234 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 11127 241 Total_LBAs_Written 0x0030 253 253 --- Old_age Offline - 3192 242 Total_LBAs_Read 0x0030 253 253 --- Old_age Offline - 66461 249 Unknown_Attribute 0x0032 100 100 --- Old_age Always - 9346 

Was ist los?