Nach RAID5 Erweiterung Partition weg

[SteKo]

Nein, zumindest nicht über die Konsole. Geht womöglich dann mit Neustart im RAID-BIOS.

Über den Mangel an Dokumentation hab ich mich seinerzeit bei der Einrichtung geärgert und war verwundert wie wenig (auch) allgemeine Informationen zu finden seien.
Dies hier überrascht und freut n mich zugleich, endlich mal handfeste Informationen zu bekommen .
Ich wollte grundsätzlich nicht hardware - basierend aufbauen, aber Win7 nötigte mich dazu, da ja die RAID5 Unterstützung zwar da war, aber eben wohl nur im Server 2008 freigeschaltet wird.

Na, dann mal "Vielen Dank, für die Blumen"...........
Aber, aus Fehlern (auch wenn sie durch unangebrachte Sparsamkeit anderer, Stichwort "sparen wir uns ein Byte") muss man lernen und das Beste machen.

Ich kanns nur noch mal sagen: Vielen Dank für Deine Unterstützung

Gruß Stephan

 

[Ernst@at]

Das ganze funktioniert bei RAID-Arrays ja prima - die per Treiber vorgegaukelte Hardware liefert auf ein "Identify Device"-Command die Information, dass seine Blöcke, die per LBA adressiert werden, 1K, 2K oder 4K statt 512Bytes groß sind. Somit kann man bei gleicher LBA-Anzahl ein Vielfaches an Kapazität adressieren.

Warum sind nur die HDD-Hersteller nicht auf diese Idee gekommen? Damit wäre der Welt das GPT-Format erspart geblieben...
Ich stell mir da die Frage, wozu es den 48-bit LBA Mode gibt, wenn dann alle Entwickler zu blöd sind, und mit 32Bit weitergurken (manche schaffen nicht mal das, weil ihnen der Umgang mit arithmetische Operationen mit unsigned words, overflow und borrow nicht erklärt wurde).

Wenn schon Daten auf dem Datenträger sind, ist eine derartige Verwandlung allerdings gemein. Irgendwie muss das RAID-Xpert oder filesystem-mount diese Veränderung durch Umschreiben der MBR- und GPT-Informationen getrickst haben - oder hast Du schon mit Testdisk etwas auf die Platte zurückgeschrieben? Ich hab im oberflächlichen Sichten der Testdisk-Source zwar schon Andeutungen für eine derartige Funktionalität, das GPT-Format schreibend zu verändern, gefunden - ob das per "Write MBR" funktioniert, aber noch nicht nachgeforscht. Lesen und interpretieren tut es diese Infos schon. Bei dynamischen Basisdatenträgern wurde das bis jetzt nicht implementiert...

wird fortgesetzt

 

[SteKo]

Aha, da ist es im Grundsatz wohl nicht mal schlecht. Zwar nicht sauber programmiert, aber wohl doch an sich nicht wirklich verkehrt.
Es scheiterte dann wohl an der Ausführung.

Nein, TestDisk wurde nur lesend verwendet. Zwecks Sicherung der Daten.
Außer ganz am Anfang, wenn ich mich richtig erinnere. Da habe ich ja nicht mal das Laufwerk gesehen, also den ganzen Datenträger.
Dann habe ich TestDisk laufen lassen, fand dann das laufwerk auch und nach dem darauffolgenden Neustart fand auch Win das LW wieder.
Wieso eigentlich dyn. Basisdatenträger? Ich dachte, entweder Basisdatenträger oder dyn. Datenträger.
Oder verwechsel ich da jetz was?

 

[Ernst@at]

Ich will mich jetzt nicht festlegen, ob wir den Karren ohne teuren Zusatzaufwand aus dem Dreck ziehen können - das sehen wir später, wenn wir fertig analysiert haben.
Der Lichtblick ist, dass die Daten nicht verlustig werden, weil sie ja im Moment noch offenbar anstandslos mit Testdisk und GetDataBack samt Ordnerstruktur rauskopiert werden können.

Die NTFS-filesystemroutinen scheinen mit den Änderungen der fiktiven Hardware-Voraussetzungen nicht so ganz glücklich zu sein. Woran das liegt und ob wir das händisch beheben können, wird sich zeigen.

Erst noch ein Test, ob der HxD richtig waltet:
Gib mal rechts in der Menüleiste im Sektorfeld 1 (+Enter) ein. Positioniert er auf 800?
Mit dem ">" Button - kommt man damit auf 1000, 1800, 2000

Nachtrag zu deiner Frage:
Es gibt Basis(MBR) und GPT(GUID) Datenträgerformat.
bei beiden eine dynamische Variante, die je nach Win-Version unterstützt wird oder nicht

 

[SteKo]

Zu deinem HxD Test: Ja, funktioniert genauso, wie du es beschrieben hast.
Ok, das hab ich verstanden.
Es dauert zwar schon ein wenig, aber nach stichprobenartigen Kontrollen des Dateiinhaltes, wage ich die Vermutung (oder eher die Hoffnung), dass die Daten noch konsistent sind.

Beim ersten Initialisieren fragt das BS ja nach MBR oder GPT. Und danach kann man ja die Datenträger von Basis auf dynamisch umwandeln. Oberflächlich uninteresssant, außer bei SoftRAID. Unten drunter, da du ja unterscheidest, wohl signifikant unterschiedlich.

 

[Ernst@at]

Ja, signifikant unterschiedlich
Nicht nur für Soft-Raid, sondern auch für volumeübergreifende Laufwerke (spanned) oder einfache Kapazitätserweiterung nicht am Stück.
Zur Recovery allerdings ein HORROR

Na denn, das ganze nochmal unter Berücksichtigung der 2K Sectorsize
Lass dich durch zwischendurch eingestreute Kommentare mit * beginnend nicht verwirren, da rechne ich nur was aus, und finde es praktischer zur Überprüfung, wenn es hier steht

HxD Aufruf unter User mit Administratorrechten
- Menü: Extras/open disk/physical disk/hard disk 2 (Häkchen bei "open as readonly" NICHT entfernen!
- Menü: File/New (es erscheint in der Anzeige ein zweiter Reiter "untitled1")
- auf Reiter "harddisk 2" klicken
========= extrahieren MBR+GPT-Einträge
* 00000000828 0A00000000000000 firstuse LBA: 10
* 10*2048= 0x5000

- Menü: Edit/select block/start-offset: 0 , length: 5000 , hex, OK
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken und in das kleine Rechteck rechts unter ... 0E 0F klicken
- Strg+V (überträgt den Inhalt aus der Zwischenablage) im popup "file size change": OK
========= extrahieren NTFS-Bootrec
* lt. testdisk start-CHS = 4-28-25
* 4*255*63+28*63+25-1= 66048*2048=8100000 [ursprünglich Sektor 264192*512]

- auf Reiter "harddisk 2" klicken
- Menü: Edit/select block/start-offset: 8100000 , length: 4000 , hex, OK (übertrag den Start-Wert mit copy&paste, beim letzten Mal hast Du eine 0 zuviel getippt )
- 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
========= extrahieren NTFS-Bootrec-Mirror
* lt testdisk size in sectors = 1953058816
* (66048+1953058816-1)*2048= 0x3A3528FF800 [ursprünglich ((66048+1953058816)*4-1)*512= 3A3528FFE00 ]
* Da wird u.a. der Hase im Pfeffer liegen...
* warum das beim letzten Mal nicht funktioniert hat? auch eine 0 zuviel?

- auf Reiter "harddisk 2" klicken
- Menü: Edit/select block/start-offset: 3A3528FF800 , length: 800 , 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
========= extrahieren GPT-Mirror
* 00000000820 1FE7849100000000 backup LBA: 2441406239
* 00000000830 16E7849100000000 lastuse LBA: 2441406230
* (2441406230+1)*2048= 0x48C2738B800
* (2441406239-2441406230)*2048= 0x4800

- auf Reiter "harddisk 2" klicken
- Menü: Edit/select block/start-offset: 48C2738B800 , length: 4800 , hex, OK (übertrag den Start-Wert mit copy&paste)
- 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 "extract2.txt" /speichern
- HxD beenden

den File extract2.txt stellst Du als Anhang ins Post,,,
das wird die düstere Lage erhellen

 

[SteKo]

Na dann hoffe ich mal, dass dieses File hier etwas Licht ins Dunkel bringen kann.

Datei ca 281kb... ich mach mal schnell ein zip

Ergänzung (25. November 2009)

So hier das zip

 

[Ernst@at]

Das sieht nach erstem Augenschein höchst informativ von den richtigen Stellen aus.
Werde das am späten Nachmittag daheim in den Dechiffrierer stecken.

Ist immer eins mehr oder weniger, als man glaubt, ich hab an Sectorsize 512 gedacht dabei:

========= extrahieren NTFS-Bootrec-Mirror
* lt testdisk size in sectors = 1953058816
* (66048+1953058816-1)*2048= 0x3A3528FF800 [ursprünglich ((66048+1953058816)*4-1)*512= 3A3528FFE00 ]
* Da wird u.a. der Hase im Pfeffer liegen...

das sollte richtigerweise
... [ursprünglich (66048+1953058816)*2048-1*1024= 0x3A3528FFC00 ]
heißen, tut der Aussage aber keinen Abbruch.

Der NTFS-BootRec-Mirror sitzt nun an der falschen Stelle, weil der letzte Sektor in dem Partition-Bereich jetzt (da die Sektorgröße statt 1K jetzt 2K ist) um 1K früher beginnt.
Zwar kein Grund, die Partition nicht zu mounten, aber trotzdem Inkonsistenz.
Den eigentlichen Grund werden wir erst im Bootrec-Inhalt finden

Vorne hat uns der Trick mit der Änderung der Sektorsize die alten ursprünglichen GPT-Infos zerbombt, Mal sehen, was im alten GPT-Mirror steht (der am Ende des früheren 4TB-Arrays noch erhalten sein muss).

Darf ich Dich also noch zu einem Tänzchen mit dem HxD bitten?

HxD Aufruf unter User mit Administratorrechten
- Menü: Extras/open disk/physical disk/hard disk 2 (Häkchen bei "open as readonly" NICHT entfernen!
- Menü: File/New (es erscheint in der Anzeige ein zweiter Reiter "untitled1")

========= extrahieren alten GPT-Mirror
* 00000000420 FFA4D4E800000000 backup LBA: 3906249983
* 00000000430 EEA4D4E800000000 lastuse LBA: 3906249966
* (3906249966+1)*1024= 0x3A35293BC00
* (3906249983-3906249966)*1024= 0x4400

- auf Reiter "harddisk 2" klicken
- Menü: Edit/select block/start-offset: 3A35293BC00 , length: 4400 , 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 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
- Menü: File/Save as... einen Ordner auswählen und als Dateinamen "extract3.txt" /speichern
- HxD beenden

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

 

[SteKo]

So, schön langsam kenn ich mich mit HxD aus...
Also hier der gewünschte Bereich.
Des macht ja richtig Spaß (wenns ned so unnötig wie ein Kropf wär, wegen Hirnlosigkeit gewisser Menschen), ned immer gleich format oder was auch immer zu benutzen...
Erinnert mich irgendwie an meine früheren C64-Zeiten...
Alles neu is ja auch irgendwie langweilig, des kann ja jeder...

 

[Ernst@at]

Jaaa - so hat es früher ausgesehen.
eine Microsoft reserved Partition, wo sie noch nicht wissen, was sie da reinschreiben sollen Wie wär's einfach einstweilen mit 'nem GPT-Bootloader-Loader?
und Dein heißersehnter Datenpartition-Eintrag

Ich meld' mich dann gegen 18:00 mit den Ergebnissen, die uns hoffentlich sofort ein Licht aufgehen lassen, wie man das wieder hinmurksen kann...

Ist der Scan inzwischen schon zu einem Ende gekommen oder hat sich das Getdataback unhöflich verabschiedet?
Nicht vergessen, das scan-result zu speichern - vielleicht brauch ich da noch was davon...

 

[SteKo]

Na, da is ja wenigstens no ned Hopfen und Malz verlorn....
Ja, die reserved partition und den tollen basic data partition eintrag hab ich auch scho gesehen.
Wo is da jetz was von GPT-Bootloader Loader??
Hmm?? So stehts wohl zur Zeit drin, oder wie?

Alles klar.

Nein, leider nein, da ich auch gleichzeitig die Sicherung ziehe, ist er immer noch damit beschäftigt, steht bei 66%. Sowieso, speicher ich dann ab, wenn er denn mal fertig ist.......
Oder soll ich lieber die Sicherungsaktion über TestDisk abbrechen?

 

[Ernst@at]

Nööö, lass es ruhig laufen...

Es gibt ja noch die Einschränkung, dass man ohne EFI-fähiges Board nicht von einem GPT-Datenträger bööten kann, was ja an sich völliger Unsinn ist.
Man muß sich ja nicht mit dem BIOS unterhalten, wenn das noch zu dumm ist.

Da der Code im MBR nicht ausreicht (außer bei AMD-RAID, da sind die Sektoren größer ), um eine bootfähige Partition im GPT-Wirrwarr zu finden, könnte man den Code einfach in diese Reserved Area legen und vom MBR dorthin springen. Dieser GPT-Loader sucht dann den eigentlichen Bootloader in einer der Partitions und dann geht alles wie gehabt...

Ergänzung (25. November 2009)

Nun, hier die Auswertungen

MBR+GPT-Informationen neu:

===== MBR INFORMATION ===== at LBA=0 [COLOR="Red"]sectorsize=2048[/COLOR]
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) [COLOR="red"]sectorsize=2048[/COLOR]
. 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)
00000000818 0100000000000000 current LBA: 1
00000000820 1FE7849100000000 backup  LBA: 2441406239
00000000828 0A00000000000000 firstuse LBA: 10
00000000830 16E7849100000000 lastuse  LBA: 2441406230
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) [COLOR="Red"]sectorsize=2048[/COLOR]
. Partition entry 1
00000001000 A2A0D0EBE5B93344 . partition type
00000001008 87C068B6B72699C7 .. GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
00000001010 59DD2C673E974A4D . unique partition
00000001018 86387A56753082D5 .. GUID: 672CDD59-973E-4D4A-8638-7A56753082D5
00000001020 0002010000000000 Part first LBA: [COLOR="red"]66048[/COLOR]
00000001028 FF516A7400000000 Part last  LBA: [COLOR="red"]1953124863[/COLOR]
00000001030 0000000000000000 Attribute flags:
00000001038 0000000000000000 . Partition Name:
00000001040 0000000000000000 ..
00000001048 0000000000000000 ...
00000001050 0000000000000000 ....
00000001058 0000000000000000 .....
00000001060 0000000000000000 ......
00000001068 0000000000000000 .......
00000001070 0000000000000000 ........
00000001078 0000000000000000 .........'....................................'
. Partition entry 2-128  *** unused ***

Der NTFS-Bootrec findet sich am richtigen Sektor 66048 (bei Sectorsize=2048)

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


===== NTFS INFORMATION ===== at LBA=66048 [COLOR="Red"]sectorsize=2048[/COLOR]
000081001FE 55AA             Boot signature='55AA'... valid
00008100000 EB5290           jump around... OK
00008100003 4E54465320202020 NTFS ID... OK
0000810000B 0004             Bytes per sector: [COLOR="red"]1024 ==> ERROR *** <> sectorsize ***[/COLOR]
0000810000D 04               Sectors per cluster: 4 ==> Clustersize=4K
0000810000E 0000             reserved sectors: 0
00008100010 000000           always zero...OK
00008100013 0000             not used...OK
00008100015 F8               <Media descriptor>
00008100016 0000             always zero...OK
00008100018 3F00             Sectors per track: 63
0000810001A FF00             # heads: 255
0000810001C 00040200         # hidden sectors: [COLOR="red"]132096 ==> ERROR *** <> current LBA ***[/COLOR]
00008100020 00000000         <not used by NTFS>
00008100024 80008000         <not used by NTFS>
00008100028 FF9FD2E800000000 Total Sectors: 3906117631
.                            ==> NTFS Mirror at sector: [COLOR="red"]3906249727 ==> ERROR *** > max LBA ***[/COLOR]
00008100030 00000C0000000000 Cluster# of $MFT: 786432
.                            ==> $MFT at sector: 3277824
[COLOR="Blue"]*  bei sectorsize=1024:      4*786432+132096= 3277824*1024= 0xC8100000[/COLOR]
00008100038 0200000000000000 Cluster# of $MFTmirr: 2
.                            ==> $MFTmirr at sector: 132104
[COLOR="blue"]*  bei sectorsize=1024:      4*2+132096= 132104*1024= 0x8102000[/COLOR]
00008100040 F6000000         Clusters/File Record Segment: 246
00008100044 01000000         Clusters/Index Block: 1
00008100048 37124B1C5F4B1CBE Volume Serial #
00008100050 00000000         checksum

Der NTFS-Bootrec-Mirror befindet sich zwar im richtigen Sektor 1953124863 (bei Sectorsize=2048), ist aber um 1024 Bytes zu weit hinten:

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

===== NTFS INFORMATION ===== at LBA=1953124863 [COLOR="Red"]sectorsize=2048 offset=1024[/COLOR]
3A3528FFDFE 55AA             Boot signature='55AA'... valid
3A3528FFC00 EB5290           jump around... OK
3A3528FFC03 4E54465320202020 NTFS ID... OK
3A3528FFC0B 0004             Bytes per sector: 1024
3A3528FFC0D 04               Sectors per cluster: 4 ==> Clustersize=4K
3A3528FFC0E 0000             reserved sectors: 0
3A3528FFC10 000000           always zero...OK
3A3528FFC13 0000             not used...OK
3A3528FFC15 F8               <Media descriptor>
3A3528FFC16 0000             always zero...OK
3A3528FFC18 3F00             Sectors per track: 63
3A3528FFC1A FF00             # heads: 255
3A3528FFC1C 00040200         # hidden sectors: 132096
3A3528FFC20 00000000         <not used by NTFS>
3A3528FFC24 80008000         <not used by NTFS>
3A3528FFC28 FF9FD2E800000000 Total Sectors: 3906117631
.                            ==> NTFS Mirror at sector: [COLOR="Red"]3906249727  ==> ERROR *** <> current LBA ***[/COLOR]
3A3528FFC30 00000C0000000000 Cluster# of $MFT: 786432
.                            ==> $MFT at sector: 3277824
3A3528FFC38 0200000000000000 Cluster# of $MFTmirr: 2
.                            ==> $MFTmirr at sector: 132104
3A3528FFC40 F6000000         Clusters/File Record Segment: 246
3A3528FFC44 01000000         Clusters/Index Block: 1
3A3528FFC48 37124B1C5F4B1CBE Volume Serial #
3A3528FFC50 00000000         checksum
.                                               Mirror <=> original  *** MATCH ***

Resümee:

Irgendwas (RaidXpert ???) hat bei der durch die Migration geänderte Sektorsize scheinheilig und schlampig den MBR und die GPT Informationen richtiggestellt.

Auf der Strecke geblieben ist der NTFS-Bootrec-Mirror, der jetzt nicht am Sektorbeginn, sondern 1028 Bytes tiefer danach, ab der Mitte des Sektors sitzt.
Der Inhalt vom Original und vom gleichlautenden Mirror lässt zu wünschen übrig, da steht alles noch so wie früher drin und führt zu mehreren Konflikten
- Sektorgröße ist falsch
- damit auch die Clustergröße
- NTFSBootrec Mirror-, $MFT- und $MFTMirr-Pointer zeigen daher in den Wald

Ich werde mir jetzt noch die GPT-Mirrordaten zur Brust nehmen, mein Analyzer streikt dabei (noch, aber nicht mehr lange )
Nebenher werd ich ein bisschen rechnen und nachdenken, wie wir den Schaden beheben,
und außerdem recherchieren, ob in dem Datendschungel des NTFS-Filesystems noch irgendwo die jetzt falsche Sektorsize/ Sectors per Cluster zur internen Verwirrung abgespeichert sein könnte...

 

[SteKo]

Ahja,

das heißt:

Die falsche Sektorgröße ist ein sich fortpflanzender Fehler, der durch dieses Dilemma eben alles verursacht hat.
Da war meine Annahme, das wohl grundsätzlich (nutzdatenbasierend) alles an seinem Platz ist, aber eben die essentiellen Informationen, die ein BS braucht, um mit einer Partition etwas anfangen zu können, sind durch obigen Fehler nicht am richtigen Platz, richtig.
Alles nur wegen der blöden Sektorgröße....

So wie ich deine Ausführungen lese, scheint da schön langsam ein Hoffnungsschimmer am Horizont zu erscheinen.... Da wär ja richtig gut.

Aber gut Ding will Weile haben.
Im Übrigen... nicht den armen Compi abschießen, der kann doch nix dafür, dass das Proggi launisch is, wie ne schwangere Frau....

Glück Auf!!!

 

[Ernst@at]

So, jetzt hab ich den alten GPT-Mirror auch

===== GPT INFORMATION =====   (at LBA= 3906249983) sectorsize=1024
. Mirror
. Header info
3A35293FC00 4546492050415254 Signature: 'EFI PART'
3A35293FC08 00000100         Version: 1.0
3A35293FC0C 5C000000         Hdrlength: 92
3A35293FC10 A36820BE         Header CRC32: crc verification not yet coded
3A35293FC14 00000000         (reserved)
3A35293FC18 FFA4D4E800000000 current LBA: 3906249983
3A35293FC20 0100000000000000 backup  LBA: 1
3A35293FC28 1200000000000000 firstuse LBA: 18
3A35293FC30 EEA4D4E800000000 lastuse  LBA: 3906249966
3A35293FC38 2A82D16B8873F243 . Disk
3A35293FC40 B8410B7BD706C1BF .. GUID: 6BD1822A-7388-43F2-B841-0B7BD706C1BF
3A35293FC48 EFA4D4E800000000 PE start LBA: 3906249967
3A35293FC50 80000000         Number of PEs: 128
3A35293FC54 80000000         Size of PE: 128
3A35293FC58 2E3E4301         PE CRC32: crc verification not yet coded
3A35293FC5C 00..             start of reserved area ..
3A35293FFFF     ..00         .. end of reserved area

===== PE INFORMATION =====   (start LBA= 3906249967) sectorsize=1024
. Partition entry 1
3A35293BC00 16E3C9E35C0BB84D . partition type
3A35293BC08 817DF92DF00215AE .. GUID: E3C9E316-0B5C-4DB8-817D-F92DF00215AE
3A35293BC10 475CBA1702E1D249 . unique partition
3A35293BC18 A6178312D0090819 .. GUID: 17BA5C47-E102-49D2-A617-8312D0090819
3A35293BC20 1200000000000000 Part first LBA: 18
3A35293BC28 1100020000000000 Part last  LBA: 131089
3A35293BC30 0000000000000000 Attribute flags:
3A35293BC38 4D00690063007200 . Partition Name:
3A35293BC40 6F0073006F006600 ..
3A35293BC48 7400200072006500 ...
3A35293BC50 7300650072007600 ....
3A35293BC58 6500640020007000 .....
3A35293BC60 6100720074006900 ......
3A35293BC68 740069006F006E00 .......
3A35293BC70 0000000000000000 ........
3A35293BC78 0000000000000000 .........'Microsoft reserved partition........'
. Partition entry 2
3A35293BC80 A2A0D0EBE5B93344 . partition type
3A35293BC88 87C068B6B72699C7 .. GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
3A35293BC90 BF4CE0540B217948 . unique partition
3A35293BC98 817887CD00992F76 .. GUID: 54E04CBF-210B-4879-8178-87CD00992F76
3A35293BCA0 0004020000000000 Part first LBA: 132096
3A35293BCA8 FFA3D4E800000000 Part last  LBA: 3906249727
3A35293BCB0 0000000000000000 Attribute flags:
3A35293BCB8 4200610073006900 . Partition Name:
3A35293BCC0 6300200064006100 ..
3A35293BCC8 7400610020007000 ...
3A35293BCD0 6100720074006900 ....
3A35293BCD8 740069006F006E00 .....
3A35293BCE0 0000000000000000 ......
3A35293BCE8 0000000000000000 .......
3A35293BCF0 0000000000000000 ........
3A35293BCF8 0000000000000000 .........'Basic data partition................'
. Partition entry 3-128  *** unused ***

für heut hab ich die Schnauze voll so ein saublöder Fehler war das...

Werd mal die Nacht drüber schlafen wo da noch was zu ändern sein könnte außer im jetzt falschen NTFS-Header/Trailer
So ganz kler ist mir noch nicht, wie Testdisk da trotzdem Daten rauskriegt, obwohl die Extent-Informationen im GPT-PE auf Basis 4K Sektoren sind und es dann im NTFS mit 2K weitergeht. Vielleicht hilft mir morgen ein Blick in die Source

 

[SteKo]

Na dann mal Gute Nacht,

werd jetz auch die Koje aufsuchen. Morgen bin ich leider tagsüber nicht am Rechner.
Dafür ist die GetDataBack-Analyse endlich fertig.

Ernst, ich kenn das... Zwar nicht in dieser ins System vertieften Situation, aber saublöde Fehler, die einem im Nachhinhein klar werden und man meint, des kann doch ned sein... Das war doch klar, Mensch...

 

[Ernst@at]

Ein neuer Tag, und die bisherigen Erkenntnisse haben sich gesetzt.

Da das nette AMD-RAID beim Migrieren von 4 auf 5TB die Sektorsize von 1K auf 2K geändert hat, ist das mit folgenden Auswirkungen verbunden:
- die physischen Sektoradressen halbieren sich
- Daten, die früher in ungeraden Sektoren lagen, sind jetzt in der zweiten Hälfte des davorliegenden Sektors zu finden und nicht mehr direkt adressierbar.

Das war wohl auch der Grund, warum nach der Migration die GPT-Informationen neu geschrieben werden mussten, weil die auf Sektor 1 beginnen müssen und der GPT-Header-Mirror am letzten Sektor naturgemäß auch eine ungerade Adresse hat.
Lustig dabei die Tatsache, dass die unbenutzte "Microsoft Reserved Partition" gar nicht übernommen wurde. Ein weiteres Fakt, dass es AMD war- M$ hätte nicht darauf verzichtet

Glücklicherweise werden (außer der obengenannten) alle GPT-Datenpartitions an 1MB-Grenzen aligned angelegt, und begannen daher an geraden Sektoradressen.
Die innere Struktur einer NTFS-Partition ist auf Clustern aufgebaut, die Clustersize ist beim Init zwischen 512 und 64K wählbar - Default 4K (was bei Dir der Fall war)
Unter der alten Sektorsize von 1K bestand also ein Cluster aus 4 Sektoren
Unter der neuen Sektorsize von 2K muß jetzt ein Cluster aus 2 Sektoren bestehen

Der NTFS-Header (Bootrec) hat in seinen Informationen derzeit unverändert die alte Sektorgröße, alte Anzahl Sektoren/Cluster und die alten Sektoradressen vom Beginn der Partition und der alten Anzahl der Sektoren gesamt gespeichert, ebenso die Clusternummern von $MFT und $MFTMirr - was bei Anwendung der alten Sectors/Cluster-Werte + alter Beginnsektor zu einer Fehlpositionierung führt und darauf nicht zugegriffen werden kann.
Der Mirror des Bootrec am Ende der Partition wird auch nicht gefunden, weil die nach alten Werten errechnete Sektoradresse ungerade ist und noch dazu doppelt so groß und daher außerhalb des Arrays liegt.

Nun besteht die Hoffnung, durch Richtigstellung in den Bootrec-Daten
- des Beginnsektors der Partition (auf halben Wert)
- der Sectorsize (auf doppelten Wert 2K)
- der Anzahl Sektoren/Cluster (auf halben Wert 2)
- der Gesamtzahl Sektoren (auf (halben (Wert+1))-1)
- und kopieren dieser Daten an den Beginn des letzten neuen Sektors als Mirror
(der alte Mirror beginnt derzeit in der Mitte dieses Sektors)

alles wieder ins Lot zu bringen.
Andere sektorspezifische Informationen dürften bei richtigem Design nicht noch irgendwo anders in dem NTFS-Filesystem abgespeichert sein, da passiert hoffentlich alles nur noch auf Clusterebene. Nach obiger Korrektur ist ein Cluster wieder 4K, aber besteht nur mehr aus 2 Sektoren der Größe 2K(statt aus 4 je 1K), was nur für den Zugriff auf physischer Ebene relevant ist (zumindest bis zum Treiber, auf den Memberplatten findet der I/O dann sowieso mit 8 Sektoren je 512Bytes statt) - NTFS-Filesystem intern wird logisch immer clusterweise gearbeitet.

Da ich sowas bisher noch bei keiner Datenrettung veranstaltet habe, ist der Ausgang leider ungewiss. Es liegt an Dir, zu entscheiden, ob wir das durchführen. Mein Gefühl dabei verrate ich Dir nicht, um dich nicht zu beeinflussen - es sind ja Deine Daten

Derzeit hast Du noch die Möglichkeit, die Daten per testdisk zu sichern. Je nach vorhandener Kapazität auf Deinen anderen Datenträgern weiß ich nicht, ob Du alles oder nur das wichtigste daraus extrahieren willst oder schon hast. Kannst Dir ja noch ein paar TB besorgen und weitersichern...

Wenn das Experiment schiefgeht, ist alles was am Array war, verloren - dann hilft nur noch Neuinitialisierung als GPT-Datenträger, Neupartitionieren, Quick-Format und Restore der bis dahin gesicherten Daten (alternativ dazu die Auflösung des RAID5 und Neuorganisation auf Einzelplatten ).

 

[SteKo]

Soo,

jetz bin ich auch wieder da. Anstrengender Tag heute...
So, das hört sich ja alles ganz positiv an...
Ich würd grundsätzlich sagen, das machen wir.
Aber ich werde erst noch alles, worauf ich zugreifen kann, sichern.
Falls diese Sache gut geht, alles bestens, wenn nicht, dann kann ichs wieder aufkopieren.
Je nachdem, wie es bei dir zeitlich aussieht, könnten wir es heute frühabend oder morgen angehen.

 

[Ernst@at]

Zugreifen solltest Du ja wohl auf alles können...
Ich werd heute abend noch ein paar screenshots von Getdataback haben wollen und Sa dann die Aktion. So hast Du noch genug Zeit zum Sichern...
Wenn Du zuwenig Platten dazu hast, gäbe es noch eine Möglichkeit...

 

[SteKo]

Na dann... werd ich dir die Screenshots zu gegebener Zeit machen.
Was für eine Idee hast denn, wenn mir die Platten ausgehen?

 

[Ernst@at]

Nimm eine vom RAID - der kann auch mit 5