Backup schlägt fehl

[naniii]

Hi,

vor 2 Wochen ist beim Backup der Fehler bereits aufgetreten. Habe gparted fix/check funktion angewendet. Danach ging das backup. Nun erneut der Fehler.
Vielleicht muss ich detaillierter mit tools wie fsck.ext4 arbeiten? Oder die SSD ist nach 9 Jahren trotzt guter smart werten am Ende? Habt Ihr Erfahrungen/Ideen dazu?

• Samsung no Name SSD, also keine evo
• ext4 filesystem
• backup tool clonezilla

 

[Lotsenbruder]

sda4 is broken. Dürfte wohl hin sein.

 

[naniii]

Es war letztes mal die selbe Partition.

 

[Lotsenbruder]

Hast Du bei der Platte mal die Smartwerte ausgelesen?
Von welchem OS und DE sprechen wir?

 

[naniii]

Manjaro Xfce
SAMSUNG MZNLN512HCJH-000L1

 

[Donnerkind]

trotzt guter smart werten

Also wenn ich mir den Wert 233 ansehe, sieht das gar nicht nach einem guten Smart-Wert aus.

 

[Lotsenbruder]

Ich würde versuchen, wenn kein weiteres Backup vorhanden ist, möglichst viele Daten manuell zu kopieren.
Der Platte würde ich keine 5millimeter mehr trauen.

 

[Uridium]

Mit OpenSeaChest testen. Einzig der 'short dst' (drive self-test) kann etwas dauern (max 10min). Der Rest geht fix. Die Ausgabe am besten bei 0x0.st oder via Codetags posten. Laufwerk sg0 ggf. anpassen (werden bei --scan unter 'handle' gelistet).

openSeaChest_SMART --scan
openSeaChest_SMART -d /dev/sg0 -i
openSeaChest_SMART -d /dev/sg0 --shortDST --captive
openSeaChest_SMART -d /dev/sg0 --SATInfo
openSeaChest_SMART -d /dev/sg0 --smartCheck
openSeaChest_SMART -d /dev/sg0 --deviceStatistics
openSeaChest_SMART -d /dev/sg0 --showSMARTErrorLog
openSeaChest_SMART -d /dev/sg0 --smartInfo

 

[naniii]

@Donnerkind wieder was gelernt

OpenSeaChest log https://pastebin.com/4tB9rhKc

Werde es mit gparted nochmal fixen, backup durchführen und nach einer neuen SSD schauen.

 

[Uridium]

Keine Ahnung, was das für ein Fehler auf dem Screenshot ist. Letztlich verweist er auf einen logischen Datei- und keinen physikalischen Fehler. Edit: Obwohl... ist ja sda4. Vielleicht sagt das Logfile, auf das er verweist, mehr aus. Sämtliche SMART Logs sprechen gegen einen HDD defekt. Und nach meiner Erfahrung protokollieren die internen Controller Fehler peinlichst genau. Dass bei dieser blühend weißen Weste zwei Fehler in derart kurzer Zeit "duchgeschlüpft" sind (was theoretisch möglich ist, da der interne Paritätscheck nicht 100% abdecken kann), halte ich dennoch für sehr unwahrscheinlich. Die Controller sperren den Sektor in dem Moment und geben ihn erst wieder frei (relocate) wenn er neu geschrieben wird. Im ersten Fall wird ein 'Read Error' protokolliert, im zweiten ein 'Relocate'. Beides ist nicht in den Smart Logs. Da kann auch was anderes dazwischenfunken (Memory defect, CPU overheat, Netzteilschwäche, etc).

Poste mal ein detaillierteres SMART Log:
sudo smartctl -x /dev/sda

Ich würde einen Memtest, CPU Stresstest und langen DST (drive selftest) (4h) machen.
Ausschließen kann ich es nicht, dass sie defekt ist. Nur, wenn sie es nicht ist, ist ein Neukauf auch nicht besonders förderlich. Memtest und Stresstest würde ich mindestens machen.

Wo wird das Backup denn hin gesichert? Externe USB HDD? Vielleicht macht die Stress (low-power, etc..) und zieht das System in den Abgrund.

 

[naniii]

Also das log aus der Bildmeldung wurde nicht geschrieben.
https://pastebin.com/prYawYFr

Memstest und co. vor Ewigkeiten gemacht, werde ich schauen wie ich die nächsten Tage zu komme.

Dieses Backup wurde über wlan via webdav gemacht und das davor auf einer externen HDD.

Mal eine andere Frage sind korrupte Filesysteme immer Hardwarefehler, oder kann so etwas beim Systemabsturz oder harten Ausschalten etc. passieren?

 

[Uridium]

Dateisystemfehler an sich sind keine Hardwarefehler (eher logische Fehler). Clonezilla ist aber grundsätzlich Filesystem semi-agnostisch. Es schaut nur mit Hilfe des Dateisystems, welche Blöcke/Sektoren belegt sind. Die Integrität des Dateisystem selbst wird ignoriert. Solche Fehler werden via Sektorcopy auch nicht erkannt.

Vielleicht ist die Fehlermeldung irreführend. WLAN Transfers würde ich jetzt nicht allzu viel Vertrauen schenken.

Der SSD Controller könnte auch kurzzeitig aussetzen. Aus dessen Sicht wäre das streng genommen kein Lesefehler.

Ich würde den Vorgang wiederholen, also das gleiche Backup nochmal machen. Wenn es ein persistenter Lesefehler ist, sollte er an der gleichen Stelle nochmal auftauchen.

 

[naniii]

Danke für die Ausführung, sehr interessant. Ich habe bisher clonezilla stable benutzt und auf eine externe HDD gebackupt. Aber ich habe mir vor ein paar Wochen ein NAS zugelegt (und war da in der Zwischenzeit mit Testen beschäftigt) und mit clonezilla alternative via WLAN über webdav dorthin backups gemacht. In beiden fällen kam es bei derselben Partitionen zum Fehler.

Ich habe die Daten der Partition kopiert auf eine externe Festplatte. Soweit so gut.

Ich habe mal kurz geschaut bei crucial und Samsung evo, aber SATA SSDs sind seltener geworden.