[RalphS]

Wie genau wurde denn das R5 eingerichtet? Per Windows' "dynamischer Datenträger" oder irgendwie anders?

Ist jetzt von der Rekonstruktion her ein bissel schwierig...aber, wenn TD in der Lage ist, das RAIDset soweit zu rekonstruieren, daß auf die Partitionen zugegriffen werden kann, dann sag ich: nutz das und schreib die Informationen so zurück auf die Platten. Mehr kann man da von TD auch nicht erwarten.

Allerdings solltest Du hinterher, soweit es nicht schon von allein passiert, einen Rebuild / Check / XXX anstoßen, also "irgendwas" das auf eine Integritätsprüfung des RAIDsets hinausläuft.

Und für die Zukunft, eben so ein Ausfall ist eine der Schwächen von RAID5 - Stichwort Write Hole -- was eben unter Umständen zu solchen Ergebnissen führen kann. Daher ist es unter Umständen sinnvoll, nach größeren Aktionen den Festplattencache zu synchronisieren (geht zB mit dem Sysinternals-Tool 'sync.exe') und Windows, wenn es mal eingefroren aussieht, ein bißchen Zeit zur Verfügung zu stellen (auch wenn ich natürlich nicht weiß, ob und wie lang Du gewartet hast). Gibt's keine Kontroll-LED für den HDD-Zugriff ist das schlecht; da müßtest Du schauen, ob Du das irgendwie in Software geregelt kriegst (in der Hoffnung, daß das trotz hängendem Windows zumindest Indizien liefert). Eine 'echte' LED ist natürlich vorzuziehen sodaß, wenn die an ist und Windows aber hängt, man halt notgedrungen warten muß.

[NCC-1701 B]

Wenn ich das richtig lese ist das ein Software RAID das von Windows verwaltet wird?

A Wenn ja selbst schuld sowas tut man nur wenn man noch alle Daten als Backup hat.

B RAID egal welches ersetzt/ist keine Datensicherung! Man sollte alles doppelt haben.

[Samstag]

Auch wenn du nicht drüber diskutieren willst wie es dazu kam, du musst ja nicht drauf antworten: Sollte der Crash auf eine ungewöhnliche negative Beschleunigung oder andere, von aussen herbeigeführte, nicht dem normalem Gebrauch entsprechenden Unwägbarkeiten entstanden sein: Die Festplatten sollten dann einzeln auf Schäden getestet werden. Da du nicht drüber diskutieren willst ist das Thema für mich durch, Antwort wird keine erwartet. Wollte es nur erwähnen.
Nächstes Thema: Ich gehe da soweit mit RalphS konform. Aber da die Platten eh schon zerschossen sind würde ich sie auch noch vollends plätten und komplett von vorne anfangen, also das Raid auflösen, Festplatten prüfen, neu einrichten und dann alles zurückkopieren. Nur so kannst du dir sicher sein auch wieder ein möglichst fehlerfreies System zu erhalten.
Das ist zwar Aufwand, aber die Datensicherheit sollte das wert sein.
Achso, darf ich fragen welches Gehäuse das ist?

Dieser Beitrag wurde von Samstag bearbeitet: 26. Februar 2016 - 12:25

[RalphS]

Naja, um Sharkoon tät ich unbesehen einen Bogen machen. Aber, wie erwähnt, das Problem mit dem R5 Write Hole bleibt. Wenn sich das System auch nicht 'extern' runterfahren läßt, also nicht auf den Soft-Off Knopf reagiert und man auch remote keine Verbindung zum Runterfahren kriegt (sei es per shutdown -m oder per Stop-Computer -ComputerName) wird man wohl damit leben müssen.

Ist doof, ganz ohne Frage, aber bei RAID5 ein Restrisiko; so arg wie bei Dir ist das zwar nicht... üblich... aber halt eben auch nicht auszuschließen.

Aus diesem Grund solltest Du auch schauen, daß Du zumindest die kritischsten Dinge anderweitig gesichert kriegst; dazu gehört auch (soweit Dein RAID-Konfigurationstool das ermöglicht) eine Kopie der RAID-Konfiguration, wo dann Offsets, Streifenbreite, beteiligte Platten etc drin stehen, damit man da im Zweifel entweder automatisiert oder ggf. händisch darauf zurückgreifen kann.

Bei so ner verdaddelten Partitionstabelle... mh, unter Unixoiden würd ich gdisk und testdisk nehmen; wenn das bei Dir auch soweit geholfen hat, seh ich keinen echten Grund, nach was anderem zu suchen. Nur halt dran denken, daß solche Tools bei RAIDsets dann nicht weiter runter kommen, denn das, was der RAID-Controller dem OS vorsetzt, ist einfach virtuell.

[dale]

Zum Write Hole

Zitat

Write hole in RAID5

Theoretically, a RAID hole phenomenon can also happen in a RAID6 consisting of the large number of member disks. RAID write hole in a RAID5/RAID1 occurs when one of the member disks doesn't match the others and by the nature of single-redundant RAID5/RAID1 it is impossible to tell which of the disks is bad. Write hole in a RAID 6 occurs when two disks don't match the others simultaneously. Such a situation can happen, for example, if the power is turned off in the middle of the full stripe write.

wenn man so was vermeiden will hat mein Hardware San mit Pufferbatterien am Controller und sowieso eine USV.....

Nochmal das Raid als Datensicherung alleine zu nehmen ist ein Fehler!

[RalphS]

Die ganze Sache hat leider mit RAID(5) nicht so besonders viel zu tun dahingehend, daß R5 dagegen einfach nicht schützt. Hardware ist Hardware und Software ist Software; wenn das Dateisystem hinüber ist, nun ja, dann muß sich das Dateisystem selber kümmern, zB per Journalling. Mit anderen Worten, hat man RAID5 und eine FAT32-Partition da drauf und schaltet die Kiste von jetzt auf gleich einfach aus, dann hat man wie bei non-RAID Dateisystemfehler, crosslinks und weiß der Geier was nicht noch.

Daß ausgerechnet die Bereiche betroffen sind wo die Partitionsinformationen stehen... ist selten, da nicht sehr wahrscheinlich (sind ja nur paar Sektoren); aber halt eben auch nicht unmöglich.

Oder vielleicht noch ein bissel anders formuliert: auch auf einem RAIDset landen kaputte und nicht-rekonstruierbare Daten, wenn da RAM-Fehler da waren, oder wenn der Download kaputt war, oder wenn die CPU wieder mal falsch gerechnet hat. Der einzige Unterschied ist halt der, daß in einer RAID-Konfiguration ein Teil des Pools ausfallen kann und das ursprüngliche Image vollständig erhalten oder zumindest vollständig rekonstruiert werden kann - soweit es im RAIDset gespeichert war.

Bloß, ganz genau DAS passiert halt nicht, wenn man insbesondere R5 den Strom unterm Hintern wegzieht: Konsistentes Datum = Speicherdatum auf der Festplatte PLUS Speicherdatum im Festplattencache und letzterer ist flüchtig; ergo RAIDset - Strom <==> Speicherdatum - Summe(Festplattencaches der beteiligten Platten). War das Set grad fleißig am Ackern, weil man was geschrieben hat, sind das auch hochgradig korrelierte Daten; mit anderen Worten, es bleibt nix übrig, woraus das RAIDset rekonstruieren könnte. Also schaun wir eine Ebene höher; hier hat zB NTFS als Dateisystem ein Journal, welches die unterbrochenen Schreibvorgänge auch nachträglich erfolgreich abschließen kann...

... jedenfalls dann, wenn der RAID-Controller nicht nach oben "geschrieben" meldet, während das aber noch gar nicht der Fall war, in welchem Fall man auch noch ein kaputtes Journal kriegen kann.

Und manchmal kommt es halt vor, daß dadurch LBA-Adressen verfälscht werden und ein harmloser Schreibvorgang sozusagen zur falschen Adresse umgeleitet wird (zB von 0xA000h nach 08000h) und wenn da dann zufällig Partitionsinformationen standen... *schulterzuck*


--- Wie gesagt. Kommt vor. Normalerweise kein Problem und mehr oder weniger entweder vom RAIDset oder vom Dateisystem automatisch korrigiert, ohne daß man was davon mitkriegt; aber, halt nicht 100% garantiert.