Noch funktionierende HDD während RAID-Recovery gestorben

S

s24!

Registered User
Guten Abend,

letzte Nacht habe ich in einem Hetzer-Server der EX-Generation die Platte 'sdb' tauschen lassen, jetzt ist 'sda' hin:

Code: 
Jan  4 18:05:18 h18 kernel: [41639.622418] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
Jan  4 18:05:18 h18 kernel: [41639.622452] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 bc c9 0e 00 00 00 08 00
Jan  4 18:05:18 h18 kernel: [41639.622479] end_request: I/O error, dev sda, sector 3167292928
Jan  4 18:05:18 h18 kernel: [41639.622504] ata1: EH complete
Jan  4 18:05:18 h18 kernel: [41639.622538] raid1: sda: unrecoverable I/O read error for block 3164141056
Jan  4 18:05:19 h18 kernel: [41640.316882] md: md2: recovery done.

Der Restore-Vorgang ist bis ca. 55% gekommen. Ich hatte sowas schon mal bei einem anderen Server; damals habe ich dann einfach ein neues (Degraded-)RAID mit 'sdb' erstellt, die Daten dorthin kopiert und im Rescue-System noch mal "nachsynchronisiert" um dann vom neuen RAID zu booten, die kaputte Festplatte tauschen zu lassen und das Ersatzgerät ins neue RAID einzuhängen - das waren aber auch nur ca. 30 GB damals, während es jetzt 2.6 TB sind (eine 12 GB große MySQL-Datenbank, ansonsten Bilder und deren drei Miniaturansichten / Thumbnails).

Daher habe ich überlegt, ob es vielleicht sinnvoller (evtl. auch schneller) wäre, ins Rescue zu booten und blockweise zu kopieren:

Code: 
dd if=/dev/sda bs=1M conv=noerror,sync of=/dev/sdb

Was meint ihr? Wie sollte ich hier am besten vorgehen, was gibt es zu beachten?


Grüße
Tim

Edit: Es ist doch korrekt, dass ich mdadm nicht dazu zwingen kann, bei einem Lesefehler fortzufahren, oder?
 
Last edited by a moderator:
Wenn der Read-Error kritisch ist wird auch eine blockweise Kopie das Problem nicht beheben, falls er überhaupt über den defekten Sektor rauskommt.
Sollte er es schaffen ist aber weiter davon aus zu gehen dass die Partition beschädigt ist und Datenkorruption sowie -Verlust besteht.

Du könntest natürlich ein e2fsck mit entsprechendem Parameter laufen lassen welcher Bad blocks ersetzen geht. Hilft zwar nicht gegen Daten-/Partitionskorruption aber dagegen dass das Raid nicht synced.

Wie wird so schön gesagt; Raid ersetzt keine Backups. MogileFS übrigens auch nicht, zumal wenn es nicht funktioniert wie es soll. Gelle =)



Übrigens: ist es ein Controller/Head-Fehler (meist nicht reproduzierbar auftretende und verschwindende Bad blocks respektiv massenweise bad blocks über die ganze Platte) oder ein Plattenfehler (oft "geclusterte" bad blocks, zB durch Headcrash)?
Eine Platte mit Controllerschaden/Kopfschaden ist meist nicht sinnvoll wiederherstellbar.
 
Ich hatte mal mit dd_rescue 2 image-datein von einer defekten hd gemacht.Eins von vorne an und eines von hinten an, so konnte ich damals vieles retten.
 
Hallo,

danke für die Anregungen & Tipps! Letztendlich haben wir wie schon angedacht einfach ein neues RAID erstellt und die Daten per rsync umgezogen ( -xrlHpEAXogDhv --delete sollte ausreichen :D). Klappte problemlos, wie erwartet.

d4f said:
Wenn der Read-Error kritisch ist wird auch eine blockweise Kopie das Problem nicht beheben, falls er überhaupt über den defekten Sektor rauskommt.
Click to expand...
Dafür ja conv=noerror, wobei mir noch aufgefallen ist, dass ich bs=<Blocksize> hätte setzen müssen, wenn diese Lösung gewünscht worden wäre.

d4f said:
Sollte er es schaffen ist aber weiter davon aus zu gehen dass die Partition beschädigt ist und Datenkorruption sowie -Verlust besteht.
Click to expand...
Dass die Daten auf den defekten Sektoren - sofern dort welche vorhanden sind, was bei einer quasi vollen Platte angenommen werden muss - hinüber sind, ist klar. Da hab ich keine Wunderheilung erwartet. =)
rsync zu benutzen, war u.a. auch gut, weil wir so eine Liste der beschädigten Dateien gekriegt haben.

d4f said:
Du könntest natürlich ein e2fsck mit entsprechendem Parameter laufen lassen welcher Bad blocks ersetzen geht. Hilft zwar nicht gegen Daten-/Partitionskorruption aber dagegen dass das Raid nicht synced.
Click to expand...
Da muss ich mich mal einlesen; klingt interessant, wenn man den dadurch entfallenden Aufwand bedenkt. Ist das im Endeffekt dasselbe wie ein erzwungenes Beschreiben der kaputten Sektoren mittels hdparm?
(Generelle Frage am Rande: Mit der "Neues-RAID-mit-rsync-befüllen-Methode" könnte ich ja die defekten Dateien ausfindig machen. Wenn ich die kaputten Sektoren einfach mittels Überschreiben durch hdparm "entsorge", liefert mir ein anschließender fsck auch die defekten Dateien? Er müsste dann ja feststellen, dass da was hinüber ist.)

d4f said:
Wie wird so schön gesagt; Raid ersetzt keine Backups. MogileFS übrigens auch nicht, zumal wenn es nicht funktioniert wie es soll. Gelle =)
Click to expand...
Hm? Der konkrete Grund für die Wiederherstellungsversuche war hier schlichtweg, dass keine 3 TB durch's Netzwerk geschoben werden sollten. Die Dateien waren und sind alle redundant im MogileFS gespeichert und die Datenbank konnte dank Master/Master-Replikation einfach umgeschaltet werden. :)

Zu dd_rescue: Was genau macht das anders als ein dd wie oben aufgeführt?
 
You must log in or register to reply here.
Back
Top