Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
6x500GB RAID5 nach defekter HDD bei Rebuild eine weitere Platte defekt gegangen
Wie sieht denn die weitere Vorgehensweis aus? Ich würd ja gern erstmal wie heut nacht angedacht, die Platten als Image sichern. Bevor wir am Server mit den Platten weiter experimentieren.
Brauchen wir eigentlich noch die Samsung 502, die wo 2% Rebuild gelaufen sind?
Ich hab im Schlaf nochmals gründlich über das Problem nachgedacht.
Die bisher verfolgte Strategie, mit beiden ausgefallenen Platten, die eigentlich keine physischen Lesefehler zeigen, wieder einen RAID zu bilden, könnte nur dann eine 100%ige Rekonstruktion erlauben, wenn ab dem Ausfall der HDD[4] bis zum zusaätzlichen Ausfall der HDD[1] während des Rebuild-Versuches keinerlei schreibende Veränderungen des Dateisystemes erfolgt sind. Das kann aber nicht ausgeschlossen werden.
Ab dem Ausfall der HDD4 lief dieser Array degraded und eventuelle Schreiboperationen wären nur mehr auf den restlichen 5 Platten abgehandelt worden. Ein Stripeset besteht hier aus 6x64KB, welches bei RAID5 mit 6 HDDs aus 5 Daten- und einem Parity-Stripe besteht.
Bei voller Funktionsfähigkeit wird beim Schreiben jedes Sektors ein Datenstripe verändert und der zugehörige Sektor des Paritystripes, welcher sich aus dem neuen Inhalt des geschriebenen Sektors und den Inhalten der anden 4 korrespondierenden Sektoren der anderen Datenstripes errechnet.
Die Position des Paritystripes rotiert über alle Platten des Arrays. Im ersten Stripeset ist sie am letzten Volume, und wandert in den nächsten Stripesets zur ersten Platte.
Im degraded Mode fehlt eine der Platten. War das Parity-Stripe auf der ausgefallenen Platte, kann dieses nicht mehr aktualisiert werden. Liegt das zu schreibende Datenstripe auf der ausgefallenen Platte, wird das Paritystripe errechnet und aktualisiert, aber nicht das Datenstripe.
Bei einer Initialisierung des Arrays wird eine Konsistenz der Inhalte von Daten- und Paritystripes hergestellt, indem das Paritystripe aus den Inhalten der Datenstripes errechnet und neu geschrieben wird; der alte Inhalt des Paritystripes findet keine Berücksichtigung.
Wenn man den Array wie in unserem Fall aus allen Platten wieder bildet, also auch mit den Daten der zeitweise ausgefallenen und bei Änderungen nicht mehr aktualisierten Platte, so würde
– ein Betrieb ohne Initialisierung die veralteten Daten von den Datenstripes der zeitweise ausgefallenen Platte lesen
- ein Initialisieren ebenso mit dem Inhalt des veralteten Datenstripes ein Paritystripe errechnen und schreiben, womit der ursrüngliche Inhalt, aus dem das Datenstripes rekonstruiert werden könnte, zerstört wird.
Der aktuelle Inhalt des Arrays ist also nur gewährleistet, wenn entweder
- die Daten aus dem degraded RAID (also ohne die zuerst ausgefallene Platte) ausgelesen werden (was unheimlich langsam vonstatten geht)
- die 6. Platte durch Rebuild aus den Informationen der verbliebenen 5 Platten rekonstruiert wird (was auch unheimlich lange dauert) und dann mit Normalgeschwindigkeit ausgelesen werden kann.
In beiden obigen Fällen müssten hinten auf die 5 Platten die Informationen eines degraded RAID geschrieben werden, damit der Controller diesen Zustand erkennt und danach operiert.
Eine Neudefinition des Arrays mit allen 6 Platten mit nachfolgender Initialisierung wäre nur dann erfolgreich, wenn sicher keine Veränderung des Dateisystems ab dem Zeitpunkt des Ausfalls der ersten Platte mehr erfolgt ist, andernfalls partieller Datenverlust durch eventuell nur schwer oder gar nicht erkennbare falsche Dateiinhalte die Folge ist.
Auch bei Verwendung eines RAID Rekonstruktors müsste dies ohne die zuerst ausgefallenen Platte erfolgen. Dieses Verfahren ist noch zeit- und platzaufwändiger, da die Daten zuerst auf ein Image umgeschrieben werden, bevor davon in einem nachfolgenden Rekonstruktionsschritt erst daraus die Daten umkopiert werden können. Dieses Verfahren empfiehlt sich nur bei beschädigtem Filesystem, oder partiellen HW-Defekten an mehreren Volumes, was in unserem Fall aber nicht zutrifft.
Am sinnvollsten wäre daher der Versuch, einen degraded Zustand mit 5 HDDs künstlich zu erzeugen – Durch Aufspielen der RAID- Info dieser Daten hinten auf alle 5 Einzelplatten und dann entweder degraded weiterzuarbeiten oder ein rebuild zu starten.
Wenn das funktioniert und dann die Daten gesichert sind, könnten wir ja einen Versuch wagen, welchen Erfolg ein Initialize bzw Initialize-Abbruch mit 6 Platten für ein Ergebnis bringen würde.
Daher wirst Du jetzt am Client den gesicherten Inhalt der HDD[4], den Du im Post #37 HDD4.zip als Datei HDD4.976768264.4904.bin gespeichert hast , auf alle anderen 5 HDDs hinten aufbringen. Dort stimmen alle Seriennummern und die HDD[4] ist als defekt gekennzeichnet.
Damit müsste ohne die HDD[4] einzuschalten, mit den restlichen wieder ohne Eingriff im BoorRomManager der Array verfügbar, aber degraded sein. (bis er vielleicht wieder die HDD[1] rauswirft, zumindest )
Vorgangsweise:
Erstmal musst Du den Inhalt, der vom BIOS überschrieben wurde, auf HDD0 wieder draufmachen.
Dazu ziehst Du dir die Datei HDD0.976768264.4904.bin auf den HxD
und öffnest die physical disk, wo die HDD[0] hängt (häckchen open as readonly wegmachen)
und positionierst auf Sektor 976768264
Dann bringst Du die Datei Datei HDD0.976768264.4904.bin zur anzeige und
machst dort Strg+A , womit alles markiert wird.
Strg+C zum Kopieren in die Zwischenablage
Dann wechselst Du in die physical disk und positionierst den Cursor
vor das erste in hex angezeigte Byte des Sektors 976768264 beim Offset 74709A1000
und überträgst den Inhalt mit Strg+B (Wenn Popup Längenänderung kommt, hast Du irrtümlich Strg+C gedrückt – Abbrechen)
Danach File/save, damit das auf die Platte geschrieben wird.
Die Datei HDD0.976768264.4904.bin schließt Du.
Aufbringen der RAID-Info für degraded Mode
Du ziehst Dir besagte Datei HDD4.976768264.4904.bin in den HxD.
Dann Edit/Select Block Start: 264A00 End: 264FFF
Strg+C zum Kopieren in die Zwischenablage
Wechsel auf die physical disk
Edit/select Block Start: 7470C05A00 End: 7470C05FFF
Inhalt übertragen mit Strg+C
Physical Disk close / Ja zu save to disk
Den letzten Absatz wendest Du auch noch auf HDD1, HDD2 HDD3 und HDD5 an.
Danach mal sehen, was der Intel-Controller dazu sagt (HDD4 abgeschaltet)
Wenn er nicht motzt und degraded sagt, dann sind wir ein Stück weiter.
Wie sieht denn die weitere Vorgehensweis aus? Ich würd ja gern erstmal wie heut nacht angedacht, die Platten als Image sichern. Bevor wir am Server mit den Platten weiter experimentieren.
Das Problem ist ja, dass wenn Du die Images sicherst, die 3x1.5TB fast voll sind. und dann?
probieren wir mal, ob wir den RAID degraded erwecken können, dann könntest Du die Daten einfach aufs neue Array rüberziehen
Ergänzung ()
Poste jedenfalls, ob das mit dem degraded funktioniert, aber noch nicht Windows hochfahren
Fein.
Wenn Du jetzt Win hochfährst, kommt das wegen der RAW-DISK (MBR ohne Eintrag) auf die Idee, die initialisieren zu wollen und frägt, ob es das tun soll. NEIN!
Dann gehen wir in den HxD am Server und schauen mal das Array an,
Sektor 0 ist sicher 0
Sektor 128 = HDD1 Sektor 0
Sektor 256 = HDD2 Sektor 0
Sektor 384 = HDD3 Sektor 0
Sektor 512 = HDD4 Sektor 0 (aus Parity auf HDD5 rekonstruiert)
ob die gelöscht sind oder noch das dortsteht, was wir von den einzelnen HDDs vorne gesichert haben. (HDDx.0.3.bin, die ersten 512 Bytes von 0 bis 1FF)
Vergleich das mal...
Ergänzung ()
Brauchen wir eigentlich noch die Samsung 502, die wo 2% Rebuild gelaufen sind?
Nein, die kannst Du platt machen. Die ist in jedem Fall nutzlos für Rekonstruktionsaktivitäten, außer als Work, wenn eine der 5 Platten kaputte Sektoren hätte zum kopieren, Sektorreparieren, zurückkopieren
Sektor 0 ist sicher 0 ist 0
Sektor 128 = HDD1 Sektor 0 auf Raid 0 in Datei steht was
Sektor 256 = HDD2 Sektor 0 auf Raid 0 in Datei 0
Sektor 384 = HDD3 Sektor 0 auf Raid 0 in Datei 0
Sektor 512 = HDD4 Sektor 0 auf Raid 0 in Datei HDD4.0.1.bin steht was.
Hab mich grad erinnert, dass das ja eine GPT-Initialisierte Platte ist, da steht von Sektor 34 bis 262177 ja ohnehin nur der unbenutze EFI-Bereich, die Datenpartition fängt erst dahinter an.
Übertrag trotzdem 0 bis 1ff
(in dieser Reihenfolge)
von HDD4.0.3.bin nach Sektor 512 (File/save)
von HDD1.0.3.bin nach Sektor 128 (File/save)
von HDD0.0.3.bin nach Sektor 0 (File/save)
Ein Neustart wird dann spätestens die Partition zeigen.
Ergänzung ()
Danach kannst Du mal prüfen, wie performant die Übertragung an den Client mit dem degraded RAID ist. Nimm ein paar GB und schaufle sie mit dem Commander auf den Client und stoppe die Zeit, damit sich abschätzen lässt, wie lange der ganze Inhalt dauern würde.
Sonst wäre vielleicht ein rebuild davor die bessere Wahl
Na, du machst es aber spannend - oder bist Du vor Freude, deine Daten im Explorer zu sehen, in Ohnmacht gefallen?
Ergänzung ()
Aha, schon wieder aus der Ohnmacht erwacht. Im ersten Freudentaumel solltest Du nicht vergessen, die 1.5TB Platten wieder auf Originalgröße zurückzusetzen mit dem Seatool, sonst könnte der Platz knapp werden
Ja, die Info's reiche ich gleich nach. Werde jetzt das neue Raid-5 wieder mit ganzen 1.5TB Platten erstellen (hoffe der Seabug ereilt mich nicht ) und werde dann die Daten vom Server zum Client holen.
Die kann genauso beim Kopieren dem Controller wieder missfallen.
Meine Milchmädchenrechnung
1 Tag rebuild + 1 Tag Copy von intakt = 2 Tage
1 Woche Copy von degraded = 7 Tage
Also eine 3.5 mal höhere Wahrscheinlichkeit, dass dabei eine Platte stirbt
Neee neee so lange dauert das nicht, ich habe hier schon ein Highspeed Netz stehen, das kopiert soeben lt. TC zwischen 80 und 85 MB/sec die Daten vom Server zum Client.
Also von degreded merke ich nix. Ist so schnell wie immer. Der kopeirt so schnell das die Platten das gar nicht merken.
Der Kopiervorgang wurde vom Client aus gestartet.
Bei größeren Dateien sogar 96 MB/sec das ist zügig oder?
Für alle die es nicht glauben mit der Geschwindigkeit.
Alle Daten sind vom alten Raid auf das neue Übertragen, es gab keine Lesefehler.
Stichprobehaltiges sichten und öffenen des Inhaltes hat keine bösen Überraschungen
gebracht.
Wenn Du noch helfen willst, weitere Erkenntnisse zu gewinnen, noch ein Experiment mit den alten Platten::
1. Anschluss aller 6 500GB am Client in der richtigen Reihenfolge und hochfahren. Raid status sollte „degraded“ sein. Ein chkdsk ohne Parameter sollte keine Fehler bringen, davon bitte den Konsol-Log. (chkdsk drive: >logfilepath)
2. im Windows Matrix Manager Auflösen und Neudefinition des RAID in der ursprünglichen Reihenfolge
--- bis hierher bleiben die Daten auf den 500GB Platten noch intakt, danach vielleicht Datenschrott
3. Möglicherweise beginnt er daraufhin selbstständig mit dem „init“ – tut er das? auch wenn er beginnt, folgendes weitermachen:
- ein chkdsk ohne Parameter, ob er da Fehler findet (log speichern) und wenn das fertig ist
- falls das init gestartet wurde, im Win durch Auflösen des RAID abwürgen
4. Runterfahren, auf alle 6 Einzelplatten mit HxD den im Anhang befindlichen Fileinhalt übertragen
Du ziehst Dir die Datei HDD4mod.bin in den HxD.
Strg+A alles selektieren
Strg+C zum Kopieren in die Zwischenablage
Öffnen einer physical disk (HDD0 bis 5, häkchen open as readonly wegmachen)
Edit/select Block Start: 7470C05A00 End: 7470C05FFF
Inhalt übertragen mit Strg+C
File/Close bei Meldung auf Platte schreiben? – OK
Nach oben zum öffnen der nächsten physical disk
5. Welchen Status hat der RAID beim Start? Failed und alle Platten invalid/error oder ready?
Danach den RAID, falls er überhaupt einen im Win Matrix Manager anzeigt, auflösen.
Na klar will ich noch helfen
Ich werde sofort loslegen...
Ergänzung ()
Alle 6 HDD's angeschlossen, zur Überprüfung der richtigen Reihenfolge beim booten CTRL I und im ROM-Manger kontrolliert.
Screenshot Boot ROM
Ergänzung ()
(chkdsk drive: >logfilepath)
Mhh, bei Eingabe der Befehlzeile kommt Zugriff verweigert.
Habe es am Server mit einer Platte getestet, geht auch nicht.
Bei chkdsk /? gibt es >logfilepath nicht, da steht gar nix von Logdatei erstellen in der Hilfe.
)
