RAID5: 1x offline member, 1x error occured, 1x member disk

Zwei der Platten schwächeln ein wenig, mit schlecht lesbaren Sektoren.

Sowas wirft zwar den Onboard-Controller beim rebuild aus der Bahn, ist aber kein Problem, das wieder ohne Datenverlust zum Laufen zu kriegen.

Als erstes werden wir nach den Fehlstellen fahnden und die ausrotten.

Dazu mach das so wie hier beschrieben ist auf allen drei 500GB Raid Platten
Die textfiles benennst Du scandelay 1/2/3 .txt
 
Das klingt ja super :p

Zur Info, falls jemand Mitlesender eine Zeitabschätzung braucht: Der Scan dauerte 2 Std pro 500GB-HD.

Files sind wieder angehängt.
 

Anhänge

Einen pending haben wir gefunden, es wäre sinnvoll, alle drei platten nochmals zu scannen, um zu überprüfen, ob die angegebenen langen Wartezeiten durch mehrfache Leseversuche oder andere Plattenaktivitäten zustandegekommen sind. Wenn es wieder an den gleichen Stellen auftritt, können wir dort auch gleich präventiv aufräumen.
Nach diesem zweiten Scan mach nochmals einen CrystalDiskInfo-Status, ob sich dabei die pendings vermehrt haben.
Danach können wir diese Bereiche(je 256 Sektoren) noch auf einzelne Sektoren eingrenzen und diese dann gezielt in ein realloc schiessen.
 
Die Vorgehensweise gefällt mir :)
Hat wieder ziemlich genau 2 Std pro HD gebraucht. Anbei die Ergebnisse.
 

Anhänge

Es ist bei dem einen Block geblieben, somit haben wir nur wenig zu tun
Mach also mit der Serial: S0MUJ1KQA03417
nochmal so einen HDDScan Read test
diesmal aber mit den Einträgen
start LBA: 190121984
end LBA: 190122239
Block: 1
 
Hm, jetzt erkennt er ihn nicht mehr als bad?
 

Anhänge

Zuletzt bearbeitet:
ja, manchmal geschehen Wunder, dann kann er das auch wieder mal lesen.
Versuche es nochmals, aber setze den Startwert auf 0 und lass ihn eine Minute werken, dann brichst Du ab und beginnst wieder mit dem obigen Start-Wert.
(damit wird der Plattencache geleert)
Poste nur, wenn er den Bad Block findet, der Rest ist uninteressant.
 
Sieh mal im CrystalDiskInfo nach, wie jetzt der Pending und reallocated count ist
 
05 100 100 _10 000000000002 Reallocated Sectors Count
C4 100 100 __0 000000000002 Reallocation Event Count
C5 253 100 __0 000000000000 Current Pending Sector Count
 

Anhänge

Potztausend, der muss sich aber gefürchtet haben, ist von selbst in die Reallocs gesprungen :D

Vorher im 20111213A-1 sah's ja noch so aus:

Serial Number : S0MUJ1KQA03417
000000000001 Wiederzugewiesene Sektoren
000000000001 Wiederzuweisungsereignisse
000000000001 Aktuell schwebende Sektoren

Hat sich eingekreist gefühlt und Selbstmord begangen...

Na, dann machen wir morgen fröhlich weiter...
 
Kann ich eigentlich noch irgendetwas vorbereiten? Und ist es eh ok, wenn ich den Rechner und die Platten durchlaufen lasse und nicht dauernd rauf- und runterfahre?
Kannst Du mir bitte auch noch kurz verraten, was Deine nächsten Schritte wäre?
danke!
Michi
 
Jetzt, wo die schwächelnden Sektoren weggeputzt wurden, sind wir fast fertig.
Wir werden einfach den RAID kontrolliert in einen degraded-Zustand versetzen und dann rebuilden lassen. Wenn nicht zusätzliche Fehlerhafte Sektoren dazukommen, läuft dann alles wieder wie gehabt. :D
 
Für mich klingt das ja noch immer nach Voodoo :freaky:
 
Zuletzt bearbeitet:
hättest Du die Frage 37 min später gestellt, wäre die Antwort Ja gewesen :)

Stell den Controller wieder auf RAID und ändere die Anschlussreihenfolge der Platten auf:

...417
...870
...058 Merke Dir, welche der Platten die 058 ist

Die Systemplatte klemmst Du ab, damit er nicht booten kann

wenn die Reihenfolge im RAID-Menü stimmt, löse den Array auf. (all data will be lost)

Danach definierst Du den RAID5 mit den drei Platten neu
Name: MyRAID
Typ: RAID5(parity)
size: Max
stripesize: 64KB


Wenn Du dann mit exit den RAID-Konfigurator verlässt, macht das BIOS ein reset und beginnt wieder mit POST

Wenn er keine Bootdevice findet, machst Du Power-Off und steckst die ...058 ab und die Systemplatte wieder an.

NAch Power-on gehst Du wieder in den RAID-Manager und siehst nach, ob jetzt tatsächlich die ...058 missing ist und der RAID im Status "degraded".
Dann prüfst Du die richtige Einstellung der Bootdevice und fährst wieder hoch.
 
Zuletzt bearbeitet:
hättest Du die Frage 37 min später gestellt, wäre die Antwort Ja gewesen:)
... wie Du das mit Deiner Zeitplanung bei all den RAID-Fehlern machst ist mir eh ein Rätsel ...

...417
...870
...058 Merke Dir, welche der Platten die 058 ist
jetzt bin ich mir unsicher und frag sicherheitshalber noch mal wegen der neuen Reihenfolge:
... 417 ("braver" RAID-member)
... 870 (Error occured - diese HD ging offline, als das RAID aber noch mit den beiden anderen HDs aktiv war)
... 058 (Offline member - ging Offline, als sich das System mit nur mehr 2 RAID-HDs aufhängte - Daten sollten aber mit ...417 noch gesynct sein)

bitte bestätige nur nochmal kurz, dass diese Reihenfolge stimmt. Danke!!!!
 
Zuletzt bearbeitet:
ich seh nochmal nach...
Ergänzung ()

Ergebnis der Überprüfung der Metadaten aus den harddiskx.txt


harddisk1: 7470C05C2C D94CC601 Generation <# MPB updates>: 29773017
harddisk3: 7470C05C2C E44CC601 Generation <# MPB updates>: 29773028
harddisk2: 7470C05C2C E54CC601 Generation <# MPB updates>: 29773029

Die #MPB Updates ist eine fortlaufende Nummer, die bei rausfallenden nicht mehr weitergezählt wird.
Somit ist nach dieser Information
harddisk2 (417) die Überlebende
harddisk3 (870) hat als zweite den Abgang gemacht
harddisk1 (058) ist als erstes rausgeflogen

somit ist die 058 jene die zuerst async wurde und daraufhin die zu rebuilden versucht, aber nicht vollendet wurde
weil 870 dabei einen Fehler aufgerissen hat.

Also müssen wir 058 rausreissen, damit anschließend das Rebuild auf diese gemacht wird.
 
ok, sorry fü rdie zusätzliche Arbeit - dann habe ich das Prinzip verstanden, dachte nur, dass die andere Platte länger gelebt hat...

jetzt verwirrt mich aber die "Recover"-Frage.
Mit "Nein" bestätigen und Array manuell auflösen?
 

Anhänge

  • IMAG0240.jpg
    IMAG0240.jpg
    308,9 KB · Aufrufe: 472
Zurück
Oben