RAID 5 - ICH9 - Metadaten wiederherstellen

[unKnown87]

Gigabyte GA-EP35-DS3P
South Bridge: Intel 82801IR ICH9R

2x ST31000340AS Firmware SD15 -> SD1A
3x ST31000528AS

Die genannten 5 Platten laufen schon seit übern Jahr im RAID5, ohne Probleme, unter Windows.

Wollte nun komplett auf Linux umsteigen, und mithilfe von mdadm, das raid unter linux mounten. Dies sollte laut Intel seit der Version 3.0 möglich.
Allerdings "musste" ich bei 2 Platten ein Firmware update machen, wegen ein Bug in dieser.
Ich vermute ganz stark, das dabei die metadaten der ersten beiden platte geändert/verschoben oder ähnliches wurde..

Suche nun nach einer möglichkeit die metadaten der beiden platten wiederherzustellen..
hab schonmal mit dem Storage manager vom intel das array überprüfen lassen, verlief fehlerfrei.
Die einzige möglichkeit die mir noch einfällt ist eine platte rausnehmen, formatieren und ein rebuild starten. Aber das sollte eher die letzte möglichkeit sein..

MfG

 

[ManOki]

bei raid5 darf nur eine platte "ausfallen", ein rebuild sollte also unmöglich sein. bzw auf die daten müsstest du jetzt schon keinen zugriff mehr haben, oder?

 

[unKnown87]

nein es läuft, das Intel Raid bios meint auch es wäre iO, es Fährt unter win normal hoch.
Aber wenn ich linux starte, werden alle platten einzeln angezeigt, das mounten als raidvolume, mit mdadm (welches die intelmetadaten auslesen kann) klappt nicht, weil es auf den ersten beiden platten keine metadaten findet.
Nach nem restart von Linux meint auch das Intel Raid bios die beiden platten wären no member disk, un d das raid failed, aber zum glück is nach nem kaltstart wieder alles beim alten.

MfG

 

[Dunkelschwinge]

Raid 5 und onboard? keine gute Idee.... schonmal grundsätzlich.
Auch die Idee die Firmware zu ersetzen bei Raidplatten ist schon mehr als grob fahrlässig und ziemlich dä....

Ich würde folgendes machern, wenn Du schon diese Konfig willst:

Daten unter Win sichern und Raid unter Linux neu aufbauen..


Sollte das Raid schon im Eimer sein (Ich kann das aus deiner Beschreibung nicht ganz rauslesen) wirst Du echt pech haben...

 

[Benji18]

Raid 5 solltest du nur mit Hardware Raid Controller machen


es gibt dafür gute gründe
Ich habe Testweise einen onbaord Raid 5 verwendet und dabei schmerzhaft feststellen müssen das ein Backup mit Acronis und das anschliessende Wiederherstellen nie funktioniert hat

das problem war das mein betriebssystem (damals Win XP) nichtmehr gebootet hat machesmal half ein fixmbr aber leider hat das nicht immer geholfen.

Probleme hatte ich auch das er mir oftmals eine Platte aus den verbund geschmissen hatte und das teil dann nen rebuild gemacht hat --> arbeitsgeschwindigkeit beim Rebuild gefühlt P1 133 MHZ

Wenn du ausfallsicherheit haben willst dann mach einen Raid 1

Wenn du ein Backup deiner Daten hast dann lösch deinen Raid Lvl und erstelle es neu und schmeiss dann das backup drüber aber das wiederherstellen von kaputten raid 5 partitionen ist so ne sache

 

[Ernst@at]

Sieh mal nach, welche BIOS-Version Du jetzt draufhast.
Die ganzen Probleme werden daher kommen, weil während des Firmware-Updates die beiden Platten ungeschützt am Controller hingen und das Gigabyte-Board hinten auf den Platten ein Backup vom BIOS draufgelegt hat und per HPA geschützt.
Der Intel-Controller ist möglicherweise damit fertiggeworden und hat seine Metadaten neu unter die HPA gesetzt.
Unter Linux wird aber standardmäßig jede HPA auf einer Platte entfernt, und damit steht am Ende der Platte das BIOS-Backup und nicht die RAID-Metadaten.

Lässt sich leicht überprüfen - eine 1TB Platte hat normalerweise 1863525168 Sektoren, mit HPA von Gigabyte um 2113 weniger. Im linux kann das per hdparm -i /dev/sd? überprüft werden.
Ist das System auch auf dem RAID, oder auf einer eigenen Platte?
Im Win ist die Sektoranzahl mit Crystaldiskinfo oder HDDScan eruierbar, wenn Du die Platten einzeln an einem non-RAID-Controller betrachtest (dazu aber alle gleichzeitig vom ICH9R strommäßig abhängen, nicht dass Du die SATA-Kabeln untereinander vertauscht)

Vorher solltest Du aber ein BIOS-update machen, damit diese Unsinnsfeature abgestellt werden kann. Auch dabei: Alle RAID-Platten dabei abhängen und erst wieder dranmachen, wenn wieder der Controller im BIOS in RAID-Mode gestellt ist!

 

[unKnown87]

Es funktioniert unter win ganz normal, völlig fehlerfrei, is halt bissle merkwürdig..

Raid 5 und onboard? keine gute Idee.... schonmal grundsätzlich.
Auch die Idee die Firmware zu ersetzen bei Raidplatten ist schon mehr als grob fahrlässig und ziemlich dä....

hät vllt noch zusagen sollen das mir das klar is, aber die intel laufen scho ganz gut, aber wie auch immer darum gehts ned..
Das nen firmware update keine gute idee "war" is mir scho klar, aber lies mal nach dem bug in der firmware SD15 und sag mir was du gemacht hättest?^^ und hab erst eine getestet obs geht, und es ging^^ is übrigens auch scho ne kleine ewigkeit her.. und es läuft ja fehlerfrei..
vllt sucht der intel raid controller ja auch woanders nach denn metadaten, weil sie nur verschoben wurde..

Naja wie auch immer wollt jetzt keine grundsätliche diskussion drüber..

.. sonder brauch jemand der sich damit wirklich auskennt, also die metadaten der anderen 3 platten auslesen auswerten und mithilfe dieser und vllt noch vorhandern metadaten der ersten beiden platten diese wiederherstellen kann.
hab von ernst@at nen paar antworten gelesen, und ich denke doch das er mir dabei helfen könnte.. naja mal abwarten


@Benji18 wiegesagt alles klar.. aber grad ned änderbar^^ außer du hast vllt so ca. 1000€ dann kauf ich mir neue platten + nen hardware raidcontroller =)

@ernst@at BIOS Version F6, ist das neuste und war denk ich auch schon vor dem firmwareupdate drauf
- bin grad nur per RD auf dem rechner und läuft grad win, raid5 aktiv, aber everst meint

LBA Sektoren 1953523055 bei den ersten beiden und
LBA Sektoren 1953525168 bei den andren 3en =)
also scheint es echt das bios zu sein, mal gleich so neben bei.. wie kann man das unterbinden?^^ kann man das bei neuren version deaktivieren?


MfG

 

[Ernst@at]

Die F6(oder auch die Beta F6b und F6c) Version sollte eigentlich default eine BIOS Einstellung "Backup to HDD: disabled" haben. Kann ja sein, dass die noch von früher drauf ist.
Jedenfalls sollte man die HPA's nicht ohne Vorsichtsmaßnahmen endgültig entfernen, weil sonst der Intel-Controller sich vielleicht nicht mehr auskennt und bei einem BIOS-Check, bei dem keine einzige der angeschlossenen Platten mehr eine HPA draufhat, dann vielleicht eine unbehebbare BIOS-POST-Loop oder Hänger entsteht

Das Unix kann man mit einem startup-Parameter daran hindern, dass es die HPA's entfernt.
Hast Du jetzt das System am RAID oder extra?

 

[unKnown87]

huch sry, das is auf ner extra platte an nem andrem controller, schau grad nach dem bios, aber die gigabyte seite is so lahm^^

edit: laut gigabyte is F6 für meins die neuste, oder ham die noch betas auf dem ftp liegen? dächte die standen sonst hier immer mit bei..

 

[Ernst@at]

F6 ist die Letzte, da kann man das Backup auf Platte abstellen, sollte aber default so sein.
Hindert das BIOS aber nicht daran, die Platten abzuklappern und wo es ein Backup findet, eine HPA drüberzustülpen

Raid 5 und onboard? keine gute Idee.... schonmal grundsätzlich.
Auch die Idee die Firmware zu ersetzen bei Raidplatten ist schon mehr als grob fahrlässig und ziemlich dä....

wie mans nimmt, ich halte es für "grob fahrlässig und ziemlich dä....", wenn man zu Sachen postet, von denen man keine Ahnung hat und sich damit traut, ein Urteil abzugeben

Ich habe Testweise einen onbaord Raid 5 verwendet und dabei schmerzhaft feststellen müssen das ein Backup mit Acronis und das anschliessende Wiederherstellen nie funktioniert hat

das problem war das mein betriebssystem (damals Win XP) nichtmehr gebootet hat machesmal half ein fixmbr aber leider hat das nicht immer geholfen.

Probleme hatte ich auch das er mir oftmals eine Platte aus den verbund geschmissen hatte und das teil dann nen rebuild gemacht hat --> arbeitsgeschwindigkeit beim Rebuild gefühlt P1 133 MHZ

Wenn du ausfallsicherheit haben willst dann mach einen Raid 1

Wenn man glaubt, dass Acronis das beste auf der Welt ist, darf man sich nicht wundern, wenn es mal(wieder) nicht funktioniert.
Ausstoß einer Platte erfolgt bei Plattenfehlern, wo die Firmware zu lange braucht, um den Fehler zu melden. Deswegen verwendet man da die RE oder kann es neuerdings bei den Platten einstellen.
RAID1 ist außer auf unattended Servern so ziemlich das Letzte, was man empfehlen sollte.

 

[unKnown87]

werd mich denn in meiner mittagspause erstma heim und nach der option im bios schauen und falls aktiviert, deaktivieren.. sollte ja dann nichts weiter passieren, da der bereich gleich bleibt? bzw wieder eingerichtet wird, da das bios vorhanden bleibt?

weisst du zufällig ob die meta daten dann eifnach wieder davor geschrieben werden? das sollte man ja einfach testen können, indme man linux sagt den hpa nicht zu ignorieren.
wär dir aber trotzdem dankbar wenn du mir denn dabei helfen könntest das bios aus dem hpa zuentfernen und die metadaten an die richtige stelle zubringen, falls der raidcontroller das dann nicht schon selbstständig macht. kann man ja erstma mit einer testen.
bzw falls dus scho woanders ausgiebig erklärt hast nen link, bei unklarheiten kann ich ja nochma nachfragen^^

MfG

 

[Ernst@at]

Ändere vorerst nichts an den BIOS-Einstellungen, zuerst sollte man ein paar Vorsichtsmaßnahmen ergreifen, um den RAID, falls er dann im Win auseinanderfällt, einfach mit ein paar Griffen wieder neu zu definieren.
Schön wäre, wenn auf einer non-RAID Platte eine BIOS-HPA gezielt angelegt wird, die immer dranhängt (für den Notfall einer BIOS-Recovery) oder zumindest im Schrank liegt.
Erst danach sollte die Funktion deaktiviert und die HPAs von den RAID Platten entfernt werden, dann der RAID neu definiert. So kann es in keinem Fall mehr Probleme geben, wenn man die Vorsichtsmaßnahme - bei einem eventuellen BIOS-Upgrade den RAID abzuklemmen, nie vergisst(wird eh keines mehr kommen, da EOL) und auch immer auf einer non-RAID Platte ein aktuelles BIOS-Backup drauf ist.
Entscheidend ist nämlich, dass eine Version drauf ist, woBIOS-Backup-to-HDD defaultmäßig disabled ist, sonst könnte bei einer BIOS-Recovery(wo die RAID-Einstellung verlorengeht) auf der ersten Platte(auch RAID-Member) wieder eine HPA draufgemacht werden.

Ergänzung (4. August 2010)

Nächstes Problem, dass ja wohl ein GPT-Format am Array initialisiert ist. Das hat es auch nicht gerade gerne, wenn das logische RAID-Volume plötzlich größer wird, wenn jetzt alle Platten volle Größe haben.

 

[unKnown87]

naja notfalls geht doch nen bios recovery auch übers floppy..
also bei aktivierter funktion, macht das bios ein backup hinten auf die 1. disk , egal an welchen controller. Also lass ich erstma nur eine platte dran, bei aktivierter funktion, und lass in 1x bis zum booten..
funktion deaktivieren und alle platten wieder dran, aber dann is bei dem backup auf der platte die funktion aktiviert? wenn man das bios übers bios exportiert, zB aufn stick, und das im notfall per diskette einspielt behält das da die einstellungen? ich denke scho, das sollte da ja reichen..

.. meld mich nochma sobald das erledigt ist..

.. edit oder kann man das manuell auf die platte sichern? dann gleich mal schauen^^

 

[Ernst@at]

Ich würd erstmal schauen,
- ob an den non-RAID-Platten am System weniger Sektoren drauf sind (Anzahl endet normalerweise immer mit ..0, ..8 oder ..6; mit HPA aber ..7, ..5 oder ..3)
- ob davon welche GPT oder dynamisch initialisiert sind
- welche BIOS-Version jetzt aktiv ist.
- ob das Backup-to-HDD in den Advanced-Einstellungen disabled ist.

Danach richtet sich die weitere Vorgangsweise.

 

[unKnown87]

ST3500630AS = LBA Sektoren 976771055
dort ist eine 200GB partion ntfs mit win7 drauf und eine mit 200gb linux extd 4 + 20gb swap, sollte noch mbr sein.. und gnu grub als bootloader

sind noch 2 weitere platten drinne, ohne partition, wurden komplett mit truecrypt verschlüsselt, werden unter win als nicht initialisiert angezeigt, das gleiche gilt für das raid5

die option im bios war aktiviert, ist nun deaktiviert, bios hab ich mir nochma aufn stick gezogen

ST3750640NS = LBA Sektoren 1465147055
bei der andren kann ichs grad nicht sagen, muss ich später nochma schauen..

werd dann auch mal schauen wie truecrypt mit der partitionstabelle regelt, ich weiß das nen header auf der platte liegt, vllt sind dort auch neben der information zum decryptn auch die partitionsgröße bzw der weg zum richtigen mbr/gpt..
dieser lässt sich einfach mit truecrypt sichern und auch wieder herstellen.. falls die platte zB von win initialisiert wird sehr nützlich^^

 

[Ernst@at]

Na schön, an den beiden Truecrypt kannst Du ja zumindest mit CrystalDiskInfo (edit/ copy option: identify device anhaken und dann Strg+C) auch die Sektoranzahl auslesen.
Es sollte sichergestellt werden, dass keine Uralt-Kopie des BIOS auf einer der Platten verbleibt:
Jede der schon Verseuchten non-RAID Platten alleine anschließen, alle anderen weg
BIOS das Backup enablen und dann einmal bis zum (fehlschlagenden) boot durchlaufen lassen - damit wird auf jeder der Platte die aktuelle F6 abgespeichert

Wenn das geschehen ist, im BIOS wieder das Backup auf disable.
dann widmen wir uns dem Problem der RAID-Platten.

 

[unKnown87]

in crystal info is nur die sysplatte500GB und die 750GB die mit am ich9 hängt, aber die 200er die mit am controller der sysplatte hängt nicht, unter everest steht die platte zwar, aber die einzige wo es nicht angezeigt wird. aber mir wärs lieber ich hau das auf keiner der platten drauf, werd wahrscheinlich noch nen raid 0 fürs sys machen, vllt auch halb 0 halb 1, mal abwarten.
Außerdem fin ichs besser wenn ich das den manuell mach, beim checksum error im bios probiert er ja trotzdem vom floppy nen neues bios einzuspielen, und wenn der chip im arsch is isses ehh egal, oder lädt der auch von der hd das bios und bootet damit bei defekten bioschip?

wegen der 200er werd ich heut abend nochma schauen, bzw vllt find ich noch währenddessen ne möglichkeit es auszulesen.

-- Disk List ---------------------------------------------------------------
(1) ST3500630AS : 500.1 GB [1-0-1, pd1]
(2) ST3750640NS : 750.1 GB [3-1-1, pd1]

----------------------------------------------------------------------------
(1) ST3500630AS
# of Sectors : 976771055

(2) ST3750640NS
# of Sectors : 1465147055

 

[Ernst@at]

Es geht ja eigentlich nur darum, zu gewährleisten, dass auf keiner der Platten mehr ein altes, sondern unbedingt die F6 drauf ist, denn wenn er eine alte findet, flasht er die im Fehlerfall wieder in den BIOS-ROM, und damit sind die RAID-Platten wieder in Gefahr.

Wenn das ein 2-Kanal SATA Zusatzcontroller ist, die lassen nur die Platte am ersten Port mit SMART- und DevID Commands erreichen. Musst Du eventuell umkabeln, damit du auch die Anzahl Sektoren der zweiten siehst

 

[unKnown87]

jo, is einer von jmicron 36x wenn ich mich recht erinner, da kann ich aber erst nach 19:00 umstecken.
wiegesagt mir wärs am liebsten wenn wir die komplett entfernen, wie verhält sich das eigentlich dann an andren mainboards? weil wollte das firmware update eigentlich an nem andren rechenr machen, aber der weigerte sich zu booten, aber könnte auch daran liegen das sie in einem raid war.. ich denke ich hatte so ein problem schonmal und nachdem ich sie mit dem raidbios zurückgesetzt hatte ging es wieder...

aber würde von ausgehen das auch auf dieser das bios is, weil das is die älteste^^ man könnte ja erstma mit dieser anfangen und schauen wie sich truecrypt dann verhält, rückgängig machen sollt eja nicht allzuschwer sein..

edit:
(1) ST3200822AS : 200.0 GB [1-0-1, pd1]

# of Sectors : 390719855

 

[Ernst@at]

Wenn Du das lieber hättest, kannst Du gerne die HPA wegmachen bei allen non-RAID-Platten. das funktioniert per MHDD oder den Plattenherstellertools(restore native size) an onboard-Controller im IDE Mode.

Bevor Du das mit den beiden RAID-Platten machst, sollte man aber vom intakten RAID den MBR/GPT des Arrays sichern und wenn dann alle RAID-Platten abgeklemmt sind, von einer der RAID-Platten die Metadaten an einem anderen Controller(oder im IDE Mode) auslesen, am besten von der zweiten (weil unter dem laufenden System sonst von der ersten+letzten der GPT-Eintrag und die RAID-Metadaten durch Korrektur zerstört werden).

Es ist auch von Vorteil, die Sicherung des MBR/GPT-Headers aufzubewahren - im Falle zB einer schwachen Boardbatterie kann die RAID-Einstellung des Controllers verlorengehen, was dann einen Start des Systemes im IDE-Mode zur Folge haben kann, und diese Einträge dann auf der ersten und letzten(Parity) Memberplatte zerstört werden, desweiteren durch Überschreiben der Metadaten diese beiden Platten zu non-RAID gemacht werden und der RAID dann FAILED ist.

Vor dem Entfernen der HPA sollte der MBR des Arrays gelöscht werden
Nach dem Entfernen der HPA von den beiden Memberplatten gleichzeitig wird der Controller damit ins FAILED gerissen(einzeln würde es jedesmal ein stundenlanges Rebuild zur Folge haben), die drei restlichen HDDs müssen zu non-RAID gemacht werden, dann mit allen 5 der RAID5 wieder aufgebaut und danach der MBR/GPT wiederhergestellt werden.

Eine anschließende Kontrolle der Arraygröße zeigt, ob sich das Ende nach hinten verschoben hat. Eine Erweiterung der letzten Partiton um diese paar Sektoren würde ich aber aus Sicherheitsgründen bleiben lassen.