Nach RAID5 Erweiterung Partition weg

[SteKo]

Hallo allesamt,

ich hab nun (wahrscheinlich wg. eigener Dummheit) ein Problem mit meinem Hardware-Raid und Windows 7.
Mein bisheriges Raid5 (5 1TB Platten, 1 Partition) wollte ich um eine 1TB Platte erweitern, was ja von AMD über die Raidxpert Konsole auch vorgesehen ist. Gesagt, getan, 6. Platte dazugehängt, auf Raid Umstellung gegangen, dort dann die freie Platte markiert, über Nacht gewartet und schon wars umgestellt.
Danach kam eine Mitteilung, dass es unter Umständen nötig ist, den Rechner neu zu starten...
Nach Ausführung dieses Neustarts erkannte das System das erweiterte Raid als leere Platte und ich hab nen Schreikrampf bekommen.....

So, nun hab ich TestDisk gefunden, gesagt, getan... er findet auch eine Partition, sagt aber was über bad sectors (leider kein foto gemacht), was aber auch verständlich ist, weil ja eine Platte mehr drin ist.

So und nun die Frage aller Fragen: Wie komme ich wieder an meine Daten?????????
Das Raid wieder zurückbauen geht ja nicht. Ich denke, es wird wohl ein logisches Problem sein, da die Sektoren, Zylinder usw. wohl nicht mehr zur Hardware passen?
Wo war der Fehler (damit mir sowas nicht nochmal passiert)? Hätte ich erst die Partition bzw. den Datenträger dynamisch machen müssen?

Ich würd mich wirklich extremst freuen, wenn hier hilfreiche Tipps kommen würden.

Grüße

Stephan

 

[Fiona]

Bad sectors kann auch mit der Geometrie in der Partitionstabelle zusammenhängen, wenn di nicht richtig ist?
Kann im Fall über das Menü Geometrie korrogiert werden.
Teile mal mit, wasin Testdisk nach bestätigen bei Analyse bei Disk steht oder mache eine Diagnose.
Wäre folgendermaßen;
Mache mal eine Diagnose nach dieser Anleitung;

Lade dir mal Testdisk Version 6.12 beta für Windows.
Link dazu gibt es hier;
https://www.computerbase.de/downloads/systemtools/festplatten/testdisk/
Starte Testdisk bestätige bei dem Log-Datei-Screen mit Enter, wähle deine betroffene Festplatte aus und bestätige mit Enter, bestätige bei Partition Table Typ Intel, bestätige bei Analyse mit Enter und setze mir einen Screenshot.
Bestätige auch bei Quick Search mit Enter (wenn nötig wegen Vista-check mit y) und setze mir auch den Screen.
Markiere mal die betroffenen Partitionen und drücke p auf der Tastatur ob deine Daten angezeigt werden oder eine Fehlermeldung.
Zurück kommst du mit q drücken.

Wenn keine Partition mit Daten gefunden wurde;
Bestätige weiter bis du zum Menü kommst wo unten steht [Quit] Deeper [Search] [Write] und gehe mit dem Pfeil auf [Deeper Search] (tiefere Suche) und lasse es laufen.
Setze mir auch einen Screenshot.
Die betroffene Partition sollte wenn du den Screen machst markiert sein.

Markiere mal die betroffenen Partitionen und drücke p auf der Tastatur ob deine Daten angezeigt werden oder eine Fehlermeldung.
Zurück kommst du mit q drücken.

Viele Grüße

Fiona

 

[Ernst@at]

Nach Ausführung dieses Neustarts erkannte das System das erweiterte Raid als leere Platte und ich hab nen Schreikrampf bekommen.....

Klar - Das trübt etwas das logische Denkvermögen, wenn man ohne Backup unterwegs war
zum Mitdenken:
- 5x1TB RAID5 = 1x 4TB Array
- 1x4TB Array = GPT Datenträger
GPT-Partitionierung hat so seine Eigenheiten, dass die Partitionierung vorne (aber nicht im MBR) eingetragen und am Ende des Datenträgers gespiegelt wird.

Nach der Migration von 5x1TB auf 6x1TB RAID5 sollte das bereits vorhandene Array weiterhin 4TB groß gewesen sein und 1 zusätzliches TB frei ...

Das Array hast Du dann auf 5TB vergrößert oder hat das der RAIDXpert gemanagt?

Jedenfalls kann man einen GPT-Datenträger nicht so einfach ungestraft größer machen...

 

[SteKo]

Hallo,

@Fiona: Die Bilder mach ich gleich. Die Partition wird gefunden, genauso wie sie VOR der Erweiterung war ABER mit folgendem Kommentar: "Warning: incorrect number of bytes per sector 1024 (NTFS) != 2048 (HD) HPFS - NTFS

Rechner macht grad Analyse

@Ernst@at:
Naja, so kann man es auch sehen... Wohin soll ich denn 4TB sichern? .... Ich weiß auf nen großes NAS...
Deine Überlegungen sind vollkommen zutreffend. Alte Partition wird als 4TB RAW angezeigt und es ist auf dem Array noch 1TB frei.

Wie geschrieben, hab ich alles über den xpert gemacht. Platte rein, markiert als zum Array hinzufügen und das wars dann.......
Nach dem Neustart wurde dann von Win7 auch ein neuer Treiber fürs Array (RAID5+1) erkannt. Danach war erst mal gar nix da.
Dann hab ich mit TestDisk eine Erkennung durchgeführt und die PArtition wurde dann auch erkannt und eingebunden und ich wurde zu einem Neustart aufgefordert.

Ok, das hab ich auch gemerkt, dass ich das doch besser gelassen hätte...

Was kann ich jetzt noch tun, um wieder an die Daten zu kommen?

Gruß Stephan

P.S.: @Ernst: Hab deine Ausführungen nicht richtige gelesen.
Jetzt Aber: Das Array ist bis jetzt 4TB. Ansonsten wie o.g. RAID5 ist 6TB. Und kann eben nicht aufs Array (bzw. die Daten) zugreifen, wird als RAW angezeigt.

 

[Ernst@at]

Ich gehe mal davon aus, dass die Migration von 5 auf 6 Platten geklappt hat.
Dann steht das ganze physisch nur etwas anders verteilt auf allen 6 Platten.
Was aber ohnehin bedeutungslos ist, weil ja über den intakten Array sowieso logisch darauf zugegriffen werden kann.

Der testdisk-scan mag zwar sehr lustig sein, ich bezweifle aber, dass man mit testdisk einen GPT-Datenträger mit einer 4TB Partition reparieren kann.
Oder hab ich irgendwo die Option "Rewrite GPT PE Information" überlesen?
Das Rauskopieren der Dateien könnte vielleicht noch funktionieren, aber wohin?
Wenn, dann würde das auch einige Tage dauern und 4TB Speicherplatz brauchen.

Bleibt also nur ein händischer Reparaturversuch, oder hat wer eine bessere Idee?

 

[SteKo]

So, nun hat das Programm den Analyselauf vollendet.
Siehe die Anhänge.
Nach Analyse zeigt TestDisk die Partition dann grün an und ich kann darüber auch in die Verzeichnisse schauen.
Wie kann ich nun dann weiter verfahren?

Ergänzung (23. November 2009)

So, hab jetzt mal für Spaß probiert, eine Datei von der Partition rauszukopieren. Hat auch einwandfrei funktioniert... nur das kann ja nicht der einzige weg sein, oder?
Es muss doch irgendwie eine möglichkeit geben, windows zu verklickern, dass da alles vorhanden ist und es ein neues Verzeichnis oder wie auch immer aufbauen soll?
Dann müsste man doch wieder auf die Daten zugreifen können, oder?

Damit mir sowas nicht nochmal passiert.
Wo war denn der Denkfehler bei der ganzen Migration?
Datenträger zuerst auf dynamisch setzen?
Es muss doch im Grundsatz möglich sein, ein laufendes Array zu erweitern.

 

[Ernst@at]

Wo der Denkfehler liegt?

Ich schrieb eigentlich davon, dass nach der Migration von 5 auf 6 Platten normalerweise das angelegte RAID5-Array in der Größe von 4TB erhalten bleibt, und ein zweites mit 1TB angelegt werden könnte.

Wie sich aus einem Blick in die Datenträgerverwaltung zeigt, wurde aber das frühere RAID5-Array von 4 auf 5 TB erweitert, lustigerweise findet er darin noch die 4TB-Partition.
Das war aber ein GPT-Datenträger, den man nicht so einfach größer machen kann.
den vorher dynamisch zu definieren, wäre dann Shit zum Quadrat.
Darin scheint das eigentliche Problem zu liegen, warum Win jetzt nicht mehr drauf zugreifen mag. Mysterien des codierten filesystem-mounts eben.

Testdisk hat offensichtlich auch keinen Plan, wie es mit den aufgefundenen Daten umgehen soll. Hardwaremäßig wird eine 5TB Device gemeldet, was dann aber zu einem Gewissenskonflikt führt, wenn man nur maximal 2TiB im Sektorfeld adressieren kann. Da hilft dann nur die verzweifelte Annahme, ein Sektor sei 2K statt 512Bytes - womit die rausgeschriebenen fiktiven Zylinder-Spur-Record und Sektorwerte völliger Unsinn sind.
Der MBR-Eintrag der GPT muss 4294967294 Sektoren groß sein, testdisk macht da 2441406239 daraus - was 1,25TB sind Hätte ein Sektor 2048Bytes, dann wären es tatsächlich 5TB; nachdem es das aber nicht geben kann, ist es nur verwirrend...
Nachtrag 28.11.: Hier muss ich testdisk Abbitte leisten - wie sich später herausstellt, hat testdisk völlig richtige und zielführende Informationen geliefert. Zu diesem Zeitpunkt war die Annahme von on-the-fly wechselnder Spurkapazität noch absurd, aber AMD RaidXpert hat uns eines Besseren belehrt...

Es kann ja durchaus sein, dass sogar das herauskopieren funktioniert - ist nur die Frage, ob auch noch, wenn die Bereiche über 2 TiB liegen.

 

[SteKo]

Wo der Denkfehler liegt?

Ich schrieb eigentlich davon, dass nach der Migration von 5 auf 6 Platten normalerweise das angelegte RAID5-Array in der Größe von 4TB erhalten bleibt, und ein zweites mit 1TB angelegt werden könnte.

ja, gut. Aber wo lag der Fehler?
Gundsätzlich wohl bei mir mit meiner fälschlichen Annahme, dass man ein RAID "einfach so" erweitern kann. Im Grunde ist diese Migrationsfunktion im RAID System vom AMD Chip wohl vollkommen sinnfrei, wenn ich sowieso neu aufsetzen muss, oder?

Wie sich aus einem Blick in die Datenträgerverwaltung zeigt, wurde aber das frühere RAID5-Array von 4 auf 5 TB erweitert, lustigerweise findet er darin noch die 4TB-Partition.
Das war aber ein GPT-Datenträger, den man nicht so einfach größer machen kann.
den vorher dynamisch zu definieren, wäre dann Shit zum Quadrat.
Darin scheint das eigentliche Problem zu liegen, warum Win jetzt nicht mehr drauf zugreifen mag. Mysterien des codierten filesystem-mounts eben.

Wie nun auch aus anderer gut informierter Quelle erfahren habe, geht das "on-the-fly" erweitern einer Partition wohl nur mit dem aktuellen Solaris Filesystem, aber eben nicht mit den gebräuchlichen.... Nun gut... auch wieder mal schlauer geworden.
Es ist wohl grundsätzlich nicht möglich ein laufendes RAID zu vergrößern (inklusive der darauf vorhandenen Partitionen).

Testdisk hat offensichtlich auch keinen Plan, wie es mit den aufgefundenen Daten umgehen soll. Hardwaremäßig wird eine 5TB Device gemeldet, was dann aber zu einem Gewissenskonflikt führt, wenn man nur maximal 2TiB im Sektorfeld adressieren kann. Da hilft dann nur die verzweifelte Annahme, ein Sektor sei 2K statt 512Bytes - womit die rausgeschriebenen fiktiven Zylinder-Spur-Record und Sektorwerte völliger Unsinn sind.
Der MBR-Eintrag der GPT muss 4294967294 Sektoren groß sein, testdisk macht da 2441406239 daraus - was 1,25TB sind Hätte ein Sektor 2048Bytes, dann wären es tatsächlich 5TB; nachdem es das aber nicht geben kann, ist es nur verwirrend...

Es kann ja durchaus sein, dass sogar das herauskopieren funktioniert - ist nur die Frage, ob auch noch, wenn die Bereiche über 2 TiB liegen.

Hmm, ok. Zusammenfassend heißt das im Groben, dass FS is zerschossen und ich muss jetzt versuchen soviel wie möglich durch rauskopieren zu sichern, danach die Partition löschen, eine neue Partition erstellen und ja nie wieder daran "rumpfuschen".
Gibts dazu irgendwelche Vorschläge, welches Programm (Datenrettung) zu empfehlen ist?

Hast Du auch einen Vorschlag, wie ich es besser machen könnte? Gibt es eine Alternative um soviel Speicherplatz sinnvoll in ein Volume zu packen? Ich habs nämlich satt auf 5 verschiedene Volumes meine Videos, Musik, Bilder usw. zusammenzusuchen.

Gruß Stephan

 

[Humptidumpti]

@Ernst@at
Ich habe mein Raid 5 jetzt schon 3 mal um je eine 1TB Platte erweitert. Das ist ebenfalls mit GPT partitioniert.

Da gabs eigentlich keine Probleme. In der Datenträgerverwaltung war dann die aktuelle Partition mit noch nicht formatiertem, bzw. partitioniertem Platz angezeigt. Sah so aus wie im Screenshot von Steko.

https://www.computerbase.de/forum/attachments/testdisk3-jpg.163672/
(Nur das das Dateiformat weiterhin NTFS war und am Anfang auch kein freier Speicherplatz mehr angezeigt wurde)

Mit diskpart hab ich dann einfach das GPT Volume erweitert.

Die Überlegung das man ein GPT Raid5 Array nicht erweitern kann ohne Datenverlust ist also hinfällig. Bei mir klappt das ja absolut problemlos.

 

[Ernst@at]

@SteKo:
Genau genommen wurde nur der Datenträger (=das RAID-Array) vergrößert, die Partitiongröße bleibt davon unberührt. Die ist ja lt Snapshot auch weiterhin 4TB.
Warum die Partition jetzt aber nicht gemounted wird, ist dank fehlender Meldungen zu diesem Thema nicht einfach eruierbar.

@Humptidumpti:
Prinzipiell sollte es ja funktionieren, wenn beim mounten eines GPT-Datenträgers festgestellt wird, dass das physische Plattenende jetzt weiter oben ist, und die Mirror-Bereiche der GPT-Einträge dorthin verlagert werden.
Irgendwas scheint hier aber schiefgegangen zu sein.

Bei normalen Basis-Datenträgern <2TiB per MBR partitioniert ist eine Größenänderung völlig egal, bei dynamischen Basis-Datenträgern geht sowas dagegen voll in die Hose

An welchem Controller betreibst Du Dein RAID5?

 

[SteKo]

Ich hab mir den Kopf nun etwas weiter zerbrochen und bin (falls falsch, bitte korrigieren) zu folgendem Schluss gekommen:

Durch den von der Software gewünschten Neustart wurden die logischen Zusammenhänge (Sektor von MBR und auch vom MFT/MFT mirr.) durch einander gewürfelt.
Das Array hatte eine Größe von 4tb, partition genauso --> Array 5tb, Partition 4tb.
Physikalisch ist durch die Migration alles halt jetzt auf 6 statt 5 Platten verteilt. Soweit, so gut.
Aber:
Die logische Abteilung ist aber irgendwie durcheinander gekommen.
Hab gerade mal mit GetDataBack experimentiert. Dort werden 3 Filesysteme angezeigt.
NTFS bei Sektor 264.192, Cluster-Größe 4 (1,82TB)
NTFS bei Sektor 264.192, Cluster-Größe 8 (3,64TB)
NTFS bei Sektor 6.555.632, Cluster-Größe 8 (3,64TB)

Wenn ich den ersten auswähle kommt als Inhalt nur Ordner mit Namen wie [00000B], [00001b] usw. ebenso die Dateien $Volume modifiziert und erstellt bei der damaligen Einrichtung des RAID.
Beim 2. kommt dann mein vermisster kompletter Verzeichnisbaum, wie auch in Testdisk, ich kann dann auch auf die Dateien als Vorschau zugreifen.
Beim 3., der als MFTmirr den Ursprung hat (beide o.g. gilt der Ursprung als uneindeutig) werden auch 2 krytische Ordner, wie bei 1. angezigt, der Rest besteht scheinbar aus Systemdateien, wie $Extend, $RECYCLE.BIN, System Volume Information, $BadClus, $Boot,usw.

Könnte es dann nicht das Problem sein, dass 2 verschiedene MFT an ein und derselben Adresse beginnen? Und dann auch noch der MFTmirr nicht ein Abbild vom 2. MFT ist und somit als Redundanz zum 2. eben nicht in Frage kommt?
Wenn ich jetzt (nach der Sicherung der Daten durch TestDisk) den MFTmirr durch den MFT ersetze, sollte doch das BS die Partition als solche wiedererkennen und benutzbar sein.

Kommentare dazu?

 

[Ernst@at]

Durch den von der Software gewünschten Neustart wurden die logischen Zusammenhänge (Sektor von MBR und auch vom MFT/MFT mirr.) durch einander gewürfelt.

wie kommst Du darauf?

Die Migration von 5 auf 6 Platten verschiebt lediglich die Stripes physisch und bildet neue Parity-Stripes, die so auf die Platten verteilt sind:

5 Platten:
stripe00 stripe01 stripe02 stripe03 --parity-
stripe04 stripe05 stripe06 --parity- stripe07
stripe08 stripe09 --parity- stripe10 stripe11
stripe12 --parity- stripe13 stripe14 stripe15
--parity- stripe16 stripe17 stripe18 stripe19
stripe20 stripe21 stripe22 stripe23 --parity-
stripe24 stripe25 stripe26 --parity- stripe27
stripe28 stripe29 --parity- stripe30 stripe31
stripe32 --parity- stripe33 stripe34 stripe35
--parity- stripe36 ...

6 Platten:
stripe00 stripe01 stripe02 stripe03 stripe04 --parity-
stripe05 stripe06 stripe07 stripe08 --parity- stripe09
stripe10 stripe11 stripe12 --parity- stripe13 stripe14
stripe15 stripe16 --parity- stripe17 stripe18 stripe19
stripe20 --parity- stripe21 stripe22 stripe23 stripe24
--parity- stripe25 stripe26 stripe27 stripe28 stripe29
stripe30 stripe31 stripe32 stripe33 stripe34 --parity-
stripe35 stripe36 ,,,


normalerweise kann mann völlig ungehindert (aber mit entsprechend schlechterer Performance) weiter auf dem Array herumgurken, und der Controller kann anhand der Stelle, an der er mit der Migration gerade ist, jeden I/O an die richtige (noch alte oder schon neue) Stelle umdirigieren.

Der Neustart war deswegen erforderlich, damit das System den vergrößerten Array als neue Device in Verwendung nehmen kann, weil offenbar das Laufwerk in Verwendung stand. (oder die Treibersoftware zu dumm für offline/onlinesetzen einer Device im laufenden Betrieb)

Hast Du den Scan-Lauf von GetDataBack gespeichert?
Wir können ja gerne mal die Daten an der entsprechenden Stellen auslesen und analysieren, ob an Deiner Vermutung was dran ist. Vorher würde ich keine schreibenden Veränderungen auf dem Array machen...

 

[SteKo]

Vielleicht habe ich mich ja nicht richtig ausgedrückt.
Ich meinte, die logische Struktur auf dem Datenträger ist in Ordnung, hardwareseitig.
FS-seitig aber nicht. Mein Ansatz war dieser, dass ich ja auf beliebige Daten (wahllos) über GetDataBack zugreifen kann, aber mir das Windows den direkten Zugriff nicht gewähren will, weil es die MFT oder den MBR nicht an passender Stelle findet, wo es nach seiner Meinung nach sein müsste.

Den Scanlauf kann ich beliebig wiederholen, da ich gleich auf Schnell-Scan gegangen bin.
Es werden auch nur diese 3 o.g. MFT zur Auswahl präsentiert.

P.S. Sende dir gern die Schritt2-Ergebnisse zu
P.P.S. Lass grad mal nen kompletten Testlauf durchlaufen... Dauer etwa 4h

 

[Ernst@at]

Bei GetDataBack kann man nach dem Scan das Suchergebnis abspeichern, dann kann man später ohne Scan wieder direkt in den Verzeichnissen und Dateien herumstöbern, und sich auch die in Frage kommenden Partitionierungsdaten wieder anzeigen lassen.

Jedenfalls scheint der richtige Partitionstart auf Sektor 264192 zu sein.
Clustergröße 8 (Sektoren) sind 4K, der Defaultwert beim Format.
Die Größe der Partition sollte 7812235264 Sektoren sein, daher der Mirror des NTFS-Bootrecs auf Sektor 7812499455 zu finden sein.

Sehen wir uns doch mal den Inhalt des Arrays mit einem Hex-Editor an.
Installier dir dazu mal HxD von hier in der englischen Version.
Anweisungen zum Auslesen der Sektoren in einer Form, die ich maschinell analysieren lassen kann, folgen ca. 21:00 wenn ich daheim bin...

Ergänzung (24. November 2009)

...hier die Anleitung:

HxD Aufruf unter User mit Administratorrechten

- Menü: Extras/open disk/physical disk/hard disk 2 (Häkchen bei "open as readonly" NICHT entfernen)
(harddisk 2 entspricht Datenträger 1 = dem RAID-Array in der Datenträgerverwaltung - weil die mit 0 zu zählen beginnt, und HxD mit 1)
- Menü: File/New (es erscheint in der Anzeigeein zweiter Reiter "untitled1")
- auf Reiter "harddisk 2" klicken
in der Anzeige sollten die erste Zeilen so aussehen:

[FONT="Lucida Console"]Offset[COLOR="Magenta"](h)   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F[/COLOR]
0000000000  33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C  [COLOR="magenta"]3ÀŽÐ¼.|ûP.P.ü¾.|[/COLOR][/FONT] <== hier steht irgendwas

wenn nicht, dann

- Menü: View/bytes per row/16/OK
- Menü: View/offset base/hexadecimal
- Menü: View/visible columns/hex and text
- Menü: View/byte group size/1​

einstellen
========= extrahieren MBR+GPT-Einträge
- Menü: Edit/select block/start-offset: 0 , length: 1000, hex, OK
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken und in das kleine punktierte Rechteck rechts unter ... 0E 0F klicken
- Strg+V (überträgt den Inhalt aus der Zwischenablage) im popup "file size change": OK
- den Cursor an der Endposition belassen, nicht in der Anzeige herumklicken!
========= extrahieren NTFS-Bootrec
- auf Reiter "harddisk 2" klicken
- Menü: Edit/select block/start-offset: 8100000 , length: 200, hex, OK (übertrag den Start-Wert mit copy&paste)
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken
- Strg+V (überträgt den Inhalt aus der Zwischenablage) im popup "file size change": OK
- den Cursor an der Endposition belassen, nicht in der Anzeige herumklicken!
========= extrahieren NTFS-Bootrec-Mirror
- auf Reiter "harddisk 2" klicken
- Menü: Edit/select block/start-offset: 3A3528FFE00 , length: 200, hex, OK (übertrag den Start-Wert mit copy&paste)
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken
- Strg+V (überträgt den Inhalt aus der Zwischenablage) im popup "file size change": OK
- den Cursor an der Endposition belassen, nicht in der Anzeige herumklicken!
========= extrahieren maxLBA
- auf Reiter "harddisk 2" klicken
- in der Menüzeile rechts auf den Button >| drücken
- Menü: Edit/select block/(den eingetragenen Start-Offset belassen) length: 200, hex, OK
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken
- Strg+V (überträgt den Inhalt aus der Zwischenablage) im popup "file size change": OK
- Menü: File/Save as... einen Ordner auswählen und als Dateinamen "extract1.txt" /speichern
- HxD beenden

den File extract1.txt stellst Du als Anhang ins Post,,,

 

[SteKo]

Hallo Ernst,

danke für die super Anleitung.

Hier die Extrakt1.txt
Leider ging der 3. Schritt (NTFS-Bootrec-Mirror) ging nicht.
Fehlermeldung: The specified offsets result in an empty selection.
Alles andere ging wunderbar.

Hier also die Datei.

Danke schon mal.
Leider dauert der Testlauf von GetDataBack noch an.... auf die ETA is auch kein Verlass.

Gruß Stephan

Ergänzung (24. November 2009)

Verflixt, jetz hatte ich vergessen den 4. Abschnitt (maxLBA) einzufügen.
Bitte nur die größere Datei beachten!!

 

[Ernst@at]

Ich bin entzückt, sowas hab ich noch nicht gesehen. (mein Analyseprogramm auch nich, das hat meist nur in IntelRAIDs geschwelgt)..
Macht der AMD-RAID doch tatsächlich eine Array-HDD mit Sektoren größer 512 Bytes daraus und testdisk hat nicht gelogen.
Deswegen waren meine Angaben für den Bootrec-Mirror auch etwas daneben (die anderen auch). Das werden wir wiederholen müssen...

So wie es aussieht, hat der Controller bei dieser Migration von 4 auf 5TB wie ein Chamäleon von einer Sektorsize von 1024 auf 2048 Bytes gewechselt, was ich irgendwie fatal finden würde.

Was mich noch interessieren würde - beim öffner der Harddisk2 zeigt HxD rechts in der Menüzeile bei Sector [Eingabefeld] pf ??? welchen Wert an?
und bei welchem Offset(h) beginnt Sektor 1 ? - bei 200, 400 oder 800 ?

Näheres folgt in Kürze

Ergänzung (25. November 2009)

Tja, da ist wohl ein wenig was durcheinandergekommen.

früher wurde eine Sektorsize von 1K angenommen, was folgende GPT-Einträge verraten

Analyzing: \\Pc10\shareddocs\SteKo RAID5 Migr\extraxt1.txt

================================================================ Sector size trial = 2*512

===== MBR INFORMATION ===== at LBA=0
000000001FE 55AA             Boot signature='55AA'... valid
.                            ... Partition Table entry 1 ...
000000001C2 EE               Partition Type: GUID Partition
000000001BE 00               Boot indicator: inactive
000000001BF 000200           Start CC-HH-SS:    0-001-02
000000001C3 FEFFFF           End   CC-HH-SS: 1023-255-63 (not CHS addressable)
000000001C6 01000000         Start    (LBA):           1 0-0-1
000000001CA 1FE78491         Size  (Blocks):  2441406239 151970-129-62 2384185MiB 2328.31GiB
.                            ... Partition Table entry 2 ...
000000001D2 00               Partition Type: unused partition entry
.                            ... Partition Table entry 3 ...
000000001E2 00               Partition Type: unused partition entry
.                            ... Partition Table entry 4 ...
000000001F2 00               Partition Type: unused partition entry

===== GPT INFORMATION =====   (at LBA= 1)
. Header info
00000000400 4546492050415254 Signature: 'EFI PART'
00000000408 00000100         Version: 1.0
0000000040C 5C000000         Hdrlength: 92
00000000410 8FFC20A9         Header CRC32: crc verification not yet coded
00000000414 00000000         (reserved)
[COLOR="Red"]00000000418 0100000000000000 current LBA: 1
00000000420 FFA4D4E800000000 backup  LBA: 3906249983
00000000428 1200000000000000 firstuse LBA: 18
00000000430 EEA4D4E800000000 lastuse  LBA: 3906249966[/COLOR]
00000000438 2A82D16B8873F243 . Disk
00000000440 B8410B7BD706C1BF .. GUID: 6BD1822A-7388-43F2-B841-0B7BD706C1BF
00000000448 0200000000000000 PE start LBA: 2
00000000450 80000000         Number of PEs: 128
00000000454 80000000         Size of PE: 128
00000000458 2E3E4301         PE CRC32: crc verification not yet coded
0000000045C 00..             start of reserved area ..
000000007FF     ..00         .. end of reserved area

===== PE INFORMATION =====   (start LBA= 2)
. Partition entry 1
00000000800 4546492050415254 . partition type
00000000808 000001005C000000 .. GUID: 20494645-4150-5452-0000-01005C000000
00000000810 FB134C0F00000000 . unique partition
00000000818 0100000000000000 .. GUID: 0F4C13FB-0000-0000-0100-000000000000
00000000820 1FE7849100000000 Part first LBA: 2441406239
00000000828 0A00000000000000 Part last  LBA: 10
00000000830 16E7849100000000 Attribute flags:
00000000838 F20B9A1391214DA3 . Partition Name:
00000000840 8B89BAC4B3BE265C ..
00000000848 0200000000000000 ...
00000000850 8000000080000000 ....
00000000858 39AED57200000000 .....
00000000860 0000000000000000 ......
00000000868 0000000000000000 .......
00000000870 0000000000000000 ........
00000000878 0000000000000000 .........'òš‘M‹º³&....€.€.9Õ..................'
. Partition entry 2  *** unused ***
...
. Partition entry 128  *** unused ***

im "alten" Sektor 2 steht jetzt Müll, weil das unter 2K Sektorsize jetzt der Sektor 1 ist

Analyzing: \\Pc10\shareddocs\SteKo RAID5 Migr\extraxt1.txt

================================================================ Sector size trial = 4*512


===== MBR INFORMATION ===== at LBA=0
000000001FE 55AA             Boot signature='55AA'... valid
.                            ... Partition Table entry 1 ...
000000001C2 EE               Partition Type: GUID Partition
000000001BE 00               Boot indicator: inactive
000000001BF 000200           Start CC-HH-SS:    0-001-02
000000001C3 FEFFFF           End   CC-HH-SS: 1023-255-63 (not CHS addressable)
000000001C6 01000000         Start    (LBA):           1 0-0-1
000000001CA 1FE78491         Size  (Blocks):  2441406239 151970-129-62 4768371MiB 4656.61GiB
.                            ... Partition Table entry 2 ...
000000001D2 00               Partition Type: unused partition entry
.                            ... Partition Table entry 3 ...
000000001E2 00               Partition Type: unused partition entry
.                            ... Partition Table entry 4 ...
000000001F2 00               Partition Type: unused partition entry

===== GPT INFORMATION =====   (at LBA= 1)
. Header info
00000000800 4546492050415254 Signature: 'EFI PART'
00000000808 00000100         Version: 1.0
0000000080C 5C000000         Hdrlength: 92
00000000810 FB134C0F         Header CRC32: crc verification not yet coded
00000000814 00000000         (reserved)
[COLOR="red"]00000000818 0100000000000000 current LBA: 1
00000000820 1FE7849100000000 backup  LBA: 2441406239
00000000828 0A00000000000000 firstuse LBA: 10
00000000830 16E7849100000000 lastuse  LBA: 2441406230[/COLOR]
00000000838 F20B9A1391214DA3 . Disk
00000000840 8B89BAC4B3BE265C .. GUID: 139A0BF2-2191-A34D-8B89-BAC4B3BE265C
00000000848 0200000000000000 PE start LBA: 2
00000000850 80000000         Number of PEs: 128
00000000854 80000000         Size of PE: 128
00000000858 39AED572         PE CRC32: crc verification not yet coded
0000000085C 00..             start of reserved area ..
00000000FFF     ..00         .. end of reserved area

===== PE INFORMATION =====   (start LBA= 2)
*** no data found ***

und den Sektor 2 (mit 2K Größe) haben wir nicht mehr ausgelesen...

naja, dann extrahieren wir mal nach neuen Erkenntnissen weiter

Anleitung folgt morgen...

 

[SteKo]

Oh mann, da wurde wohl richtig was verpfuscht... :|

So, Sektor 1 beginnt bei 800.
Sektoren ingesamt laut hxD 2441406240

Der AMD Chip hat wohl richtig gewütet.... Soll man da vielleicht mal eine Warnung ausprechen oder zumindest zur Vorsicht ermahnen?
Es handelt sich um die 750er SB von AMD.

 

[Ernst@at]

Guten Morgen nach... Südbayern?

Erstmal wollen wir uns alles genau ansehen, um das Ausmaß des "Wütens" genau festzustellen. Wann hast Du für mehrere Analyseschritte Zeit?

Was mich noch interessieren würde - welche Stripesize hat der RAID5?

 

[SteKo]

Ebenso einen guten Morgen nach Wien
Südbayern is richtig... Kolbermoor liegt bei Rosenheim.
Grundsätzlich immer, hab Urlaub.
Der Scanlauf von GetDataBack ist leider immer noch nicht abgeschlossen.

Gruß Stephan

 

[Ernst@at]

Der Scanlauf stört nicht weiter - da das Array intakt ist, müssen wir nicht dauernd umstecken oder Power-down machen zur Analyse.
Nochmal die Frage von meinem Vorpost: Verrät RaidXpert die aktuelle Stripegröße?

Mal zusammenfassen - was wissen wir bis jetzt?

Ich bin jedenfalls über den Informationsmangel entsetzt - Bei AMD wird RaidXpert nur beiläufig erwähnt, damit man weiß, es handelt sich um ein eingetragenes Markenzeichen. Alle anderen Spuren hat man verwischt, denn einige wenige tote Links zeigen noch auf die AMD-Seite, wo es mal eine Beschreibung gab. Jetzt nur mehr Treiber.
Einzig bei den Boardherstellern, welche die 7er SB's verbaut haben, gibt es Anleitungen in bunten Bildern für Noobs. Aber kein aktuelles Manual in Form eines User Guides, keine Spezifikationen.

Offenbar funktioniert der Klapperatismus nach folgender Logik:
ist die Arraygröße < 2TiB, sind die Sektoren 512 Bytes groß.
ist die Arraygröße < 4TiB, sind die Sektoren 1024 Bytes groß.
ist die Arraygröße > 4TiB, sind die Sektoren 2048 Bytes groß.

daraus würde ich folgern, der nächste Sprung auf 4096 erfolgt bei 16TiB. (Unsinn, Zweierpotenzreihe) 8TiB, dann bei 16TiBDas ist aber mit heutigen Plattengrößen und 6 Members nicht möglich
5x1TB RAID5 liegt noch unter 4TiB, 6x1TB darüber.
Wer sonst noch von diesem Unding betroffen ist, das sich ein leicht gestörtes Hirn dazu ausgedacht hat, nur um Felder mit Sektoradressen nicht größer als 4 Bytes verwenden zu müssen, kann sich ja jeder selbst ausrechnen.
Eine Migration von 3x1TB auf 4x1TB, von 4x640 auf 5x640 oder 5x500 auf 6x500 würde wohl das gleiche Ergebnis bringen, wenn einer vorausschauend schon den Array als GPT initialisiert hat. Von 3x2TB auf 4x2TB, 5x2TB auf 6x2TB und von 4x1,5TB auf 5x1,5TB hätte man es schon leichter, sich in anschließendem Wehklagen zu winden.

Du scheinst weltweit als erster dokumentierter Hoppala in die Falle getappt zu sein - meinen herzlichen Glückwunsch!

wird fortgesetzt