Während Reparatur eines SHR Fehlermeldungen im Logfile

[chaykee]

Hi,

ich besitze eine DS410j mit 4 Festplatten im SHR Verbund:
1: Samsung SpinPoint F2 EcoGreen 1.5TB (HD154UI)
2: Seagate Barracuda 3TB Hard Drive ST3000DM001
3: Seagate Barracuda 3TB Hard Drive ST3000DM001
4: Samsung SpinPoint F2 EcoGreen 1.5TB (HD154UI)

Ich wollte mein SHR nun mit einer größeren Festplatte erweitern.
Dazu habe ich mir eine Hitachi Deskstar 7K4000 4TB HDS724040ALE640 gekauft.
Die neue Festplatte hatte davor einen ausführlichen Oberflächentest durchlaufen, war alles ok.

Anschließend ging ich wie folgt vor:
DS runterfahren. Festplatte 1 (1.5TB) ausgetauscht durch die neue Festplatte (4TB), DS wieder eingeschaltet und das Volume (logischerweise degraded) reparieren lassen. Nach 20 Stunden Reparatur, irgendwo zwischen "Wird repariert (Überprüfen der Parität)" und "Wird repariert (Platte hinzufügen)" habe ich im Logfile folgende Einträge gesehen:

Information	System	2013/08/06 03:04:29	SYSTEM	System successfully checked consistency of System Volume [Swap].
Error	System	2013/08/06 02:43:22	SYSTEM	Bad sector at internal disk [4] was remapped.
Error	System	2013/08/06 02:43:20	SYSTEM	Bad sector at internal disk [4] was remapped.
Information	System	2013/08/06 02:31:10	SYSTEM	Bad sector at md2 disk4 sector 2792472639 has been corrected.
...über 20 weiterer solcher Einträge
Information	System	2013/08/06 02:31:09	SYSTEM	Bad sector at md2 disk4 sector 2792472631 has been corrected.
Error	System	2013/08/06 02:31:08	SYSTEM	Read error at internal disk [4] sector 2792472719.
Error	System	2013/08/06 02:31:08	SYSTEM	Read error at internal disk [4] sector 2792472727.
Error	System	2013/08/06 02:31:08	SYSTEM	Read error at internal disk [4] sector 2792472735.
Error	System	2013/08/06 02:31:08	SYSTEM	Read error at internal disk [4] sector 2792472743.
Information	System	2013/08/06 02:31:08	SYSTEM	Bad sector at md2 disk4 sector 2792472495 has been corrected.
Information	System	2013/08/06 02:31:08	SYSTEM	Bad sector at md2 disk4 sector 2792472503 has been corrected.
Information	System	2013/08/06 02:31:08	SYSTEM	Bad sector at md2 disk4 sector 2792472511 has been corrected.
Error	System	2013/08/06 02:31:07	SYSTEM	Read error at internal disk [4] sector 2792472591.
...über 20 solcher Einträge
Error	System	2013/08/06 02:31:06	SYSTEM	Read error at internal disk [4] sector 2792472583.
Error	System	2013/08/06 02:31:05	SYSTEM	Bad sector at internal disk [4] was remapped.
...über 20 solcher Einträge
Error	System	2013/08/06 02:30:41	SYSTEM	Bad sector at internal disk [4] was remapped.
Information	System	2013/08/06 02:16:19	SYSTEM	Bad sector at md2 disk4 sector 2767290535 has been corrected.
...über 20 solcher Einträge
Information	System	2013/08/06 02:16:17	SYSTEM	Bad sector at md2 disk4 sector 2767290455 has been corrected.
Error	System	2013/08/06 02:16:15	SYSTEM	Read error at internal disk [4] sector 2767290471.
...ca 15 solcher Einträge
Error	System	2013/08/06 02:16:15	SYSTEM	Read error at internal disk [4] sector 2767290535.
Information	System	2013/08/06 02:16:15	SYSTEM	Bad sector at md2 disk4 sector 2767290311 has been corrected.
Error	System	2013/08/06 02:16:14	SYSTEM	Read error at internal disk [4] sector 2767290311.
...ca 10 solcher Einträge
Error	System	2013/08/06 02:16:14	SYSTEM	Read error at internal disk [4] sector 2767290399.
Error	System	2013/08/06 02:16:13	SYSTEM	Bad sector at internal disk [4] was remapped.
...ca 30 solcher Einträge
Error	System	2013/08/06 02:15:36	SYSTEM	Bad sector at internal disk [4] was remapped.
Information	System	2013/08/05 23:34:25	admin	User [admin] logged in from [94.218.229.143]

Das beunruhigt mich etwas, da mein Raid gerade im Zustand degraded ist. Heißt das ich habe Daten verloren?
Die SMART informationen stehen im moment alle auf OK. Ich habe aber länger keinen Smart Test mit den Festplatten gemacht, deshalb weiß ich nicht wie alt die Infos sind.

Mich würde jetzt nur interessieren ob ich Daten verloren habe. Vielen Dank für Eure Hilfe.

 

[jan_gagel]

Hallo,

das hört sich nicht so brickelnd an. Du hast aber hoffentlich dein Backup vor dem Fummeln an den Platten nochmal aktualisiert, oder?
In der Tat liest sich das so, als ob die Platte 4 einige defekte Blöcke hat. Er schreibt da zwar, daß was korrigiert wurde, aber was mit dem Inhalt der betreffenden Sektoren passiert ist, steht leider nicht da. Außerdem wurden einige Sektoren umgelagert.

SMART schreibt solange OK hin, bis einer der SMART-Werte ausm Ruder läuft. Einige Sektoren wurden ja von der 4. Platte jetzt umgelagert, wenn es also keine Reserve-Blöcke mehr gibt, wird SMART dann ein "Fail" liefern. Du kannst aber in den SMART-Werten ablesen, wie viele reallocated sectors (umgelagerte Sektoren) es schon gibt. Meist geht ein raw-read-error (Lesefehler) voraus.

Ich würde jedenfalls erstmal die Finger still halten, solange das Raid noch degraded ist. Erst wenn es wieder OK ist würde ich ein weiteres Vorgehen planen. Derzeit kannst du ja die ausgebaute Platte mal gründlich prüfen, ob die nicht auch schon einen Schaden hat. Nach einem langen SMART-Test (ich empfehle immer einen badblocks unter Linux auszuführen) kannst du ja gerne die SMART-Werte mal anschauen, ob die sich verändert haben. Ein Vergleich zur jetzt defekten Platte in der DS lohnt sich bestimmt mal.

Für den Fall, daß du kein Backup hast, würde ich nachdem das Raid fertig ist, umgehend ein Backup anlegen. Und zwar zuerst die allerwichtigsten Sachen, dann die weniger wichtigen und am Schluß, wenn die Platte dann immer noch geht, die unwichtigen Sachen.

Ist deine momentan ausgebaute Platte in Ordnung, kannst du sie dann gegen die defekte in der DS tauschen und das Raid dann erneut reparieren lassen. Du könntest aber auch vorher die 4. Platte in der DS mit dem langen SMART-Test laufen lassen. Aber bitte vorher alle Daten sichern, denn wenn die Platte dann ausm Raid fliegt wirds ja gleich wieder degraded. Wenn der jetzige Rebuild überhaupt durchläuft.

Ciao Jan

 

[Matthieu]

(Ich gehe mal davon aus, dass die im Log erwähnte Platte die ist, die du gerade neu eingesetzt hast)
Ich selbst schaue während der Installation nur selten ins Log, aber ich könnte mir durchaus vorstellen dass bei einer neuen Platte diese Meldungen nichts besonderes sind. Defekte Sektoren treten auch bei neuen Platten auf (und je größer die Kapazität, umso häufiger werden auch diese Fehler). Erst wenn diese Fehler einen signifikanten, vom Hersteller errechneten Wert übersteigen, wirft SMART Fehler.
Wirklich vermeiden lässt sich das nur, wenn du die gesamte Festplatte vorher einem vollständigen Schreibtest unterziehst. Dann bemerkt die Platte wirklich jeden Fehler und korrigiert ihn bevor die DS erstmalig darauf zugreift. Die Frage ist nun, wie problematisch die genaue Häufigkeit ist. Was genau ist denn der aktuelle Status? Tut die DS noch etwas oder ist das Volume einfach "degraded"?

MfG Matthieu

 

[chaykee]

Jan, Matthieu,
erst mal vielen Dank für Eure Hilfe. Ein Backup habe ich genau vorher gemacht.
Zumindest von 80% der Daten, also alles was für mich wichtig war.

@Matthieu: Leider nicht
Die im Log erwähnte 4. Platte ist eine alte, nicht die neu eingesetzte.

Ich habe die Hitatchi 4TB gegen die 1. Samsung 1.5TB ausgetauscht (Disk 1), mein DS fügt immer noch die Platte hinzu:
Wird repariert (Platte hinzufügen 23.50%). Hoffentlich läuft das durch. Seit heute morgen 2:30 Uhr kommen keine Fehlermeldungen
Ich mache mal erst mal gar nichts solange das Volume repariert wird. Anschließend mache ich mal über alle Festplatten einen SMART Test.

@Jan: Ok, werde mal die ausgebaute Festplatte auf Herz und Nieren prüfen und dann, wenn das Volume erfolgreich repariert wurde und wenn die ausgebaute Festplatte ok ist, diese durch die 4. Festplatte ersetzen.

Wie bekomme ich denn am besten raus, ob ich jetzt Datenverlust hatte??
Mit dem Vergleich des Backups? Das Backup hatte ich ja genau vorher gemacht, wer weiß ob nicht da schon die Fehler da waren. Oder kann das nicht sein, weil da das SHR vor dem Festplattentausch noch nicht degraded war? *kratz

Nochmals danke

 

[jan_gagel]

Ehrlich gesagt, wie man feststellt, ob man tatsächlich einen Datenverlust hatte, weiß ich nicht. Denn auch bei einem defekten Dateisystem, was man reparieren läßt steht man da ebenso verlassen da. Denn dabei wird ja nur das Dateisystem korrigiert, der Inhalt an sich bleibt unverändert. Findet das Programm bei der Prüfung des Dateisystems dann unzugeordnette Cluster, werden die einfach abgeschnitten.

Ob vorher schon Fehler ausschlaggebend waren, kann man in deinem Fall wohl auch nicht sagen. Denn zum Einen hast du ja die Plattenfirmware, die noch mittels Prüfsumme gewisse Daten rekonstruieren kann (hier würde dann zusätzlich noch der Defekt der Sektoren ans Betriebssystem gemeldet) andererseits hat du ja noch das Raid 5 (SHR) was wiederum auf Prüfsummen zurückgreifen kann.

Wieso diese Fehler jetzt erst auftreten? Das kann daran liegen, daß diese Blöcke jetzt erst benötigt wurden. Vielleicht lagen dort die Parity-Informationen (Prüfsummen) des SHR teilweise? Oder es waren dort Daten abgelegt, die jetzt gelesen wurden und dabei wurden Unregelmäßigkeiten festgestellt.

Leider kann man so nicht wirklich beurteilen, ob es Datenverlust gegeben hat oder nicht. Im Prinzip hätte man vorher von allen Dateien eine md5-Summe berechnen können und könnte das jetzt vergleichen. Wobei das natürlich nicht wirklich funktioniert, denn da wäre man schnell bei einigen Wochen Rechenarbeit, die jetzt ein leistungsfähiger Prozessor übernehmen müßte, nicht die DS selbst.

 

[itari]

Im Prinzip hätte man vorher von allen Dateien eine md5-Summe berechnen können und könnte das jetzt vergleichen. Wobei das natürlich nicht wirklich funktioniert, denn da wäre man schnell bei einigen Wochen Rechenarbeit, die jetzt ein leistungsfähiger Prozessor übernehmen müßte, nicht die DS selbst.

also der rsync (welcher ja die Sicherung macht) macht MD5 standardmäßig

Itari

 

[jan_gagel]

gut zu wissen. Kann man denn damit ein erstelltes Backup mit dem Original rückwirkend vergleichen? Also in dem Fall des TE, ob denn die Daten des SHR irgendwie beschädigt wurden?

 

[itari]

gut zu wissen. Kann man denn damit ein erstelltes Backup mit dem Original rückwirkend vergleichen? Also in dem Fall des TE, ob denn die Daten des SHR irgendwie beschädigt wurden?

ja das geht mit dem rsync ... guck auch: http://linux.die.net/man/1/rsync

-n, --dry-run               perform a trial run with no changes made

zusätzlich kann man auch noch -v machen ... wenn alles 'gleich' ist, werden keine Aktivitäten ausgeben, ansonsten sagt das Teil, wo es Unterschiede gibt

Itari