Holt schrieb:
Das ist aber eben nötig, wenn man sie sicher halten will! Niemand sollte jemals denden es wäre einfach und günstig große Datenmengen sicher zu speichern.
Das ist richtig, dennoch kann durchaus unterschieden werden, welchen Wichtigkeitsgrad die Daten haben oder wie sie auf andere Weise wiederhergestellt werden können, um ein möglichst rentables Preis-/Leistungsverhältnis zu erziehlen.
Zum Beispiel diente das hier verloren gegangene RAID primär der Applikationsinstallation, der Aufwand wäre dann vergleichbar mit einer Windowsneuinstallation, nur ohne Windows neu installieren zu müssen, was eher der kleinere Aufwand gewesen wäre. Es hätten die Applikationen "einfach" wieder neu installiert werden müssen...
Jetzt kann man einschätzen, wie hoch das Risiko ist, dass es zu einem Fehler kommt, drüber nachdenken, feststellen, was ein Redundantes System kostet und das gegenüber dem Aufwand stellen, was die Neuinstallation kostet. Daraus kann dann jeder für sich ableiten, welche der beiden Lösungen er bevorzugt.
An anderer Stelle beispielsweise setze ich ein RAID1 (HardwareController) ein, dessen Daten jede Nacht an eine weitere Stelle gesichert werden und alle 2-3 Tage zusätzlich noch an zwei weiteren Stellen gesichert werden. Das sind dann aber auch Daten die unwiederbringlich verloren wären, käme es zu einem Ausfall...
So kann man meiner Meinung nach sehr wohl eine Kategorisierung der Daten machen und diese entsprechend behandeln.
Aber es ist dennoch ärgerlich wenn Daten verloren gehen, da es immer einen Aufwand bedeutet...
Holt schrieb:
Hast Du denn Zero Assumption Recovery überhaupt probiert?
ZAR kann RAID recovern und
R-Studio kann auch RAID recovern, aber Testdisk nicht.
Sorry, wenn hier möglicherweise ein falscher Eindruck entstanden ist...
ZAR habe ich ausprobiert, leider hatte dieses erst 4% nach 24h analysiert, was dann hochgerechnet 25 Tage zur kompletten Analyse gedauert hätte. R-Studio kenne ich bereits schon recht lange und habe da auch noch irgendwo eine verstaubte Lizenz liegen, aber da war mir bereits bekannt, dass es mit diesem Tool lange dauert, bis die Analyse durch ist. Deshalbe habe ich dieses in diesem Fall nicht ausprobiert, da es sicherlich vergleichbaren Zeitaufwand benötigt hätte.
Da wäre ich dann schneller gewesen, die Daten einfach neu zu installieren.
Wenn man sich aber nun mit dem Thema näher beschäftigt und auch die vergangenen Beiträge von Ernst berücksichtigt, kommt man zum dem Ergebnis, dass in der Regel bei dieser Art von Verlust des RAIDs, "nur" die Metadaten für die Konfiguration abhanden gekommen sein müssen. Das nun weitere Daten der Festplatte verändert wurden ist unwahrscheinlich, sofern keine Schreibzugriffe auf die HDDs durchgeführt wurden, die manuell ausgelöst worden sein müssten. Aus den Anhängen meines ersten Posts ist auch deutlich zu sehen, dass bei den beiden Platten, die nicht mehr als Member erkannt werden auch die Metadaten anders sind. Nun müssten also an dieser Stelle wieder die richtigen Metadaten hin, damit der RST wieder zufrieden ist und diese als Member erkennt. Hierzu gibt es auch Dokumentation, die beschreibt, wie die Metadaten aufgebaut sind. Nun kann man diese auch wieder manuell hergehen, diese berechnen und manuell auf die Platte schreiben. Oder man geht wie bereits an anderer Stelle über das Konfigtool des RAID-Bioses. Hierzu hatte ich in einem kleinen Testaufbau ein RAID5 erstellt, bestimmte Bereiche der Festplatte kopiert (Daten und Metadaten), den Fehler provoziert, nochmal die zuvor kopierten Daten verglichen mit dem aktuellen Stand. Daten gleich, Metadaten unterschiedlich. RAID wieder an und im Konfigtool des RAID-Bioses Eckdaten des definierten RAIDs notiert, RAID resetet und RAID mit den selben Daten und allen Platten wieder neu erstellt. Den Datenbereich wieder mit der ursprünglichen Kopie verglichen, gleich, Metadaten nicht mehr ganz identisch. Platte wird in Windows als nicht definiert angezeigt. So, jetzt kommt TestDisk zum Einsatz… Das RAID Laufwerk scannen und dann sollte dieses auch die enthalten Zuordnungstabelle wieder finden. Diese wiederherstellen, neu starten und dann ist auch die vorher vorhandene Partition/en vorhanden. Vergleich der Daten, gleich. Wiederherstellung erfolgreich…
TestDisk rettet so zwar nicht direkt das RAID, da die Daten vom RST neu erzeugt werden, rettet aber im zweiten Schritt die Daten, in dem es die Partitionstabelle wieder schreibt...
Holt schrieb:
md müsste auch mit den Metadaten von Intel Fake RAID umgehen können, es gibt die entsprechenden Option, aber frage ist, ob diese Metadaten noch intakt (genug) sind.
Möglich, dass dies auch funktioniert hätte, habe ich aber nicht mehr weiter untersucht…
Holt schrieb:
Jedenfalls habe ich dem TE zwei Recoveryprogramme genannt mit denen er Chancen hat seine Daten zu retten. Anscheinend scheut er eine kommerzielle Lösung und wartet auf eine kostenlos Lösung durch ernst@at, nur wird er da wohl lange warten müssen.
Wenn hier schon alles auf die Goldwaage gelegt wird, du hattest ZAR genannt und R-Studio wurde bereits von mir als Alternative genannt ! So viel mal dazu…
Wie ich schon oben erwähnt habe, ging es nicht um das Scheuen kommerzieller Lösungen, insbesondere nicht, wenn sich diese im zweistelligen Eurobereich befinden. Aber warum sollte ich eine kommerzielle Lösung bevorzugen, wenn eine andere Lösung wesentlich schneller zum Ziel führt ? Du fährst ja mit deinem Auto sicher auch nicht in die Werkstatt, wenn der Tank leer ist und lässt das Problem „kommerziell“ beheben, anstatt gleich selber die Tankstelle anzufahren, oder ?
--------------------------------------------
Nachdem oben schon beschriebener Test erfolgreich durchgeführt werden konnte, habe ich damit auch mein eigentliches System repariert.
Anbei nochmal kurz die Schritte (diese sind bereits auch schon an anderen Stellen benannt und wurden nicht von mir erfunden, hatte diese nur durch meine eigenen Überlegungen nachvollzogen und geprüft):
1. Windows booten und den RST deinstallieren (bin mir nicht sicher, ob der Schritt zwingend erforderlich ist, sollte eigentlich auch ohne gehen)
2. Im Systembios wieder den RAID Modus aktivieren falls noch nicht geschehen
3. Wenn das RAID-Bios hochkommt mit CRTL-I in die Konfiguration gehen
4. Sich die Daten des fehlerhaften RAID5 merken (Größe, Strip, Name)
5. Reset Disks to Non-RAID ausführen und bestätigen
6. Neues RAID mit den vorher notierten Daten und Platten erstellen und Konfiguration beenden
7. Windows/Linux starten
8. TestDisk aufrufen und das virtuelle neu erstellte Volume scannen
9. TestDisk sollte recht schnell die alten Partitionen erkennen und auflisten
10. Sind die Partitionen korrekt, dies auf die Disk schreiben; TestDisk beenden
11. Neu starten
12. Dann sollte auch schon wieder alles wie vorher sein…
13. RST wieder installieren
Alternativ kann man wie oben beschrieben auch die Metadaten manuell wiederherstellen, solang aber nichts geändert oder initialisiert wurde an den Platten, sollte der oben genannte „kurze“ Weg gehen.
Das soll weniger Schadenfreude als vielmehr die Anregung sein darüber noch einmal nachzudenken um es zu optimieren.
