Seagate Barracuda Green 5900.3 (ST2000DL003) schreiben defekte Daten beim Backup

[freeman303]

Hallo,

soeben sind mir massive Fehler beim Kopieren von Daten im Rahmen eines Backup auf eine Seagate Barracuda Green 5900.3 aufgefallen.

Ich nutze einen Areca RAID-Controller im RAID-6 Betrieb für meine Daten-Partition. Nun wollte ich vor einer größeren Konfigurationsänderung ein Backup anlegen.

Also habe ich die dafür gekauften Seagate Barracuda Green 5900.3 mit 2TB genommen. Die Disk wurde an einen Einschieberahmen angeschlossen, der intern an ein eSata Anschluss des Mainboards (ASUS Board mit AMD FX-8120) eingesteckt ist.

Nachdem die Festplatte zu ca. 80% gefüllt war, habe ich die nächste Festplatte der gleichen Baureihe angeschlossen und den Rest der Daten darauf kopiert.

Kopiert wurde ganz normal über "kopieren" des Windows Explorers am Win Server 2008 R2. Ergebnis waren zwei Festplatten oben genannten Modells mit Backup-Daten.

Um das Backup nun zu verifizieren, habe ich die Software "free commander" benutzt, der eine Vergleichen Funktion auf CRC Basis ermöglich. Das Ergebnis war erschreckend. Auf beiden Ziel-Festplatten waren jeweils ca. 50 Dateien mit Fehlern kopiert worden. Es gab keinen Zusammenhang. Weder bezüglich der geschätzten Lage der Daten auf den Plattern, noch bezüglich Dateigröße oder ähnliches. Es hat queerbeet alle möglichen Dateien erwischen: hier eine JPG Datei, ein Foto im RAW-Format, ein Video oder auch ein mehrere GB großes ISO Image, etc.

Vermutich ist innerhalb der Dateien jeweils nur ein Bit gekippt, doch das reicht schon.

Erstens finde ich es bedenklich, dass Windows mit dem Explorer einfach auf gut glück kopiert und keine Verifizierung der Daten stattfindet.

Zweitens finde ich es noch mehr bedenklich, dass die Zielfestplatte diesbezüglich keine Fehler meldet, wenn sie schon Schrott wegschreibt. Auch die SMART-Daten sind bestens!

Um nun auszuschließen, dass das Problem vom eSata-Controller oder ähnlichem hervorrufen wurde, habe ich das Backup wiederholt und die Festplatten dabei an den SATA-Anschluß des Mainboards mit anderem SATA-Kabel angeschlossen. Ergebnis: Gleiche CRC-Fehler in ähnlich großem Umfang nur bei anderen Dateien.

Es erfolgte der nächste Test: Ich habe als Backup-Festplatte eine alte Seagate Constellation 1TB HDD genommen und diese wie in einem Backup auf gleiche Weise mit gleichen Daten gefüllt. Nur zum Test. Ergebnis: Keine einzige Datei wurde mit CRC-Fehler kopiert.

Das dürfte beweisen, dass es sich hierbei um einen Fehler oder irgendeine inkompatibilität zum AMD SATA Controller und den Seagate Barracuda Green 5900.3 2TB (ST2000DL003) Modellen handelt.

Ist Euch diesbezüglich auch was bekannt? Ich finde das Ergebnis einfach erschreckend. Wären es wichtige Daten, wären diese ohne jegliche Fehlermeldung kopiert worden und man hätte Datenmüll aufbewahrt!

Woran es noch liegen könnte?

Die Seagate Barracuda Green 5900.3 arbeitet mit dem "perpendicular recording". Also noch höhere Datendichte. Allerdings dürfte sich das weniger auf speziell diese HDD auswirken, weil diese nur mit 5900 rpm arbeitet. Die Constellation Seagate, mit der alles gut verlief, läuft sogar mit 7200 rpm.

Die Barracuda Green 5900.3 hat das Advanced Format mit 4k Sektoren. Könnte es das sein? Nun, ich kann es nicht beurteilen. Die Constellation Seagate hat noch 512 Byte Sektoren.

Jeder, der etwas negatives zu dieser Festplatten Baureihe weiß, bitte ich hier zu schreiben.

Wegen der aus diesem Vorfall gewonnenen Informationen, mache ich einen neuen Thread auf, in dem es darum gehen soll, zu definieren, welche Festplatten für ein Backup genutzt werden sollten. Hier geht es zu diesem besagten Thread: http://www.hardwareluxx.de/communit...beim-kauf-achten-ein-hilfe-thread-912752.html

Grüße
Freeman

 

[Digi-Quick]

Die Smart Werte sagen etwas übder den technischen "Gesundheitszustand der Platte aus aber geben keine Auskunft über den Zustand des Dateisystems selbst.

1. womit wurde Partioniert (welches OS,m evtl. 3rd party Programm, Herstellerseitig)
2. Wie wurde formatiert? (Schnell oder Vollständig, Herstellerseitig)

Platten für Backups partitioniert und formatiert man grundsätzlich selbst und vollständig, danach kommt der Oberflächenscan. wenn das alles Fehlerfrei ist, kommt mindestens 1 Durchlauf mit h2testw, erst danach kann man relativ (!) sicher sein keine Fehler Plattenseitig zu haben und ein überprüftes Dateisystem(Auftreten können diese prinzipiell jederzeit)

3. Backups legt man nicht mit dem Explorer an (schlichtweg weil eine Verifizierung der geschriebenen Daten fehlt) - wobei es insgesamt bedenklich ist, daß der Explorer offensichtlich selbst einfache CRC Fehler beim kopieren nicht erkennt (noch ein Grund mehr, warum ich den Explodierer nicht mag - es lebe der Total Commander)

4. auch deine Seagate Constellation dürfte PMR (perpendicular recording) einsetzen, ist nämlich seit einigen Jahren Standard (seit ca.2005).

Zu guter letzt kann hier natürlich auch ein Firmwarefehler der Festplatte vorliegen, oder ein Fehler im Controller mit diesen Platten oder ein Treiberfehler.
Ganz auszuschliessen ist auch nicht der Festplatteneinschub selbst (dann müssten allerdings bei den Smartwerten die UDMA-CRC Fehler hochgehen).

P.S. Für mich ist AF/4K 'ne grosse Kundenverarsche, da der ATA Standard auch andere Sektorgrössen als 512 Byte explizit erlaubt (und auch vorgesehen sind).... man müsste allerdings sämtliche BIOSse,Controllerfirmwares und Treiber dafür anpassen, da bei diesen die Sektorgrösse mit 512 Byte sozusagen fest verdrahtet ist >> erinnert mich massv an den Y2K Bug.

 

[bluesunset]

4kbyte Sektoren gab es schon vor dem Jahre 2000 mit SCSI-Laufwerken welche MO-Disks als Disketten hatten. Damals schon mit 9,1GByte mit 4kbyte Sektoren auf zwei Datenträgern in einem Gehäuse. Bei SCSI HDDs ist auch seit einer halben Unendlichkeit die Sektorgröße um die 512Byte herum variabel.
Es überprüft kein Programm einen Kopiervorgang, da der zusätzliche verify die Kopieraktion von der Zeit her verdoppeln würde.

Ich würde freeman ggf. noch ECC-Ram nahe legen, da sein Board und die AMD CPU das immerhin unterstützen.

 

[freeman303]

Hallo,

ich habe noch weitere Tests durchgeführt.

Die beschriebenen Schreibfehler treten nur dann auf, wenn im BIOS der SATA Controller der AMD SB850 Southbridge auf 6GBit/s Modus oder auf Auto gestellt ist. Wird der SATA-Übertragungsmodus auf 3GBit/s eingestellt, passieren diese Fehler nicht mehr.

Möglicherweise liegt es auch an den Kabeln, ich glaube das aber weniger.

Freeman

 

[JensS]

Moment mal! Die Fehler scheinen ja von der Schnittstelle zu kommen, also schauen wir doch mal näher drauf.

Hast du die Möglichkeit, mal mit anderen Kabeln (im Idealfall direkt für 6GBit gedacht) gegenzutesten? 6GBit arbeitet ja mit höheren Frequenzen, dementsprechend kann ein ungeeignetes oder beschädigtes Kabel durchaus für Fehler sorgen, wenn sich die Übertragungsfehler so ungünstig summieren, dass auch der 8b10b-Code das nicht mehr erfasst.
Sonst würde ich schlicht und ergreifend auf 3GBit zurückschalten und damit leben. Bei HDDs ist das ohnehin irrelevant ob 3 oder 6GBit genutzt wird...