Hallo!
Zuallererst möchte ich meinen grossen Respekt für Ernst@at bekunden - ich finde es toll was du weisst und dass du dieses Wissen unermüdlich an Andere weiter gibst und ihnen so hilfst. Ich mache seit vielen Jahren etwas ähnliches in einem anderen Bereich (www.celestinecommunity.de) und weiss wieviel Freude soetwas bereitet, wie ermüdend das gleichzeitig ist, und wie schön es ist wenn "jemand" diese hilfe nicht als selbstverständlich nimmt.
Bitte lieber "Raid-Guru", nimm dich meines Problems an, ich habe kein Backup.....
Setup:
Achja, eines vorweg - und bitte KEINE Flames: Es gibt kein "funktionierendes" Backup, BEVOR das Ding hopps gegangen ist.
Ich versuche seit ner Woche eigenständig (&erfolglos) mein Raid0 zu reparieren, dazu kam es als ich nach einem Stromausfall einen SMART-Fehler auf der 2. RAID-Platte hatte. Da ein IMSM (Intel Maxtrix Storage Manager) Array keine Smart-Daten ausgibt, habe ich mir ein entsprechendes DOS-Tool runtergeladen und den SMART Status ausgelesen, was vermutlich dazu geführt hat dass der Superblock von der 2. HDD abgeraucht ist. Mein Problem ist dass ich mit Linux völlig im Dunklen tappe und ich mit Windows grad gar nicht hochfahren kann und auch keine RettungsCD hab.
Erste Aktion war, wie oben erwähnt die beiden Platten mit ddrescue zu sichern, was auch ohne (physikalische) Lesefehler gelang.
Leider kann ich dir auch die in den anderen "Rettungsthreads" gewünschten daten nicht als Screenshot schicken, da ich nicht wirklich weiss wie das in Linux geht und mein Dateisystem auf dem Stick sich bei jedem Runterfahren löscht.
"Eigentlich" müsste man nur den Superblock wieder ersetzen.....
Im Linux ergibt "sudo mdadm -E /dev/sdb" folgendes - das sollte doch alle wichtigen Informationen beinhalten:
"sudo mdadm -E /dev/sdc" ergibt folgendes
"sudo dmraid -R isw_dffbjddegi_Deepthought /dev/sdc" ergibt
Einen Hexeditor habe ich in Linux auch gefunden. Die ersten Sektoren des Laufwerks /dev/sdb sehen so aus:
Erwartungsgemäss ist dieser Bereich auf /dev/sdc "leer":
Zusätzlich habe ich die Sektoren 0x1000000 auf beiden Platten ausgelesen. Ergebnis:
/dev/sdb
Auf /dev/sdc sieht es so aus:
Meine Fragen
- Was brauchst du noch?
- Was soll ich tun? und ...
- Bekomme ich die Daten wieder??
Jetzt schon: DANKE!!! für deine Unterstützung
Zuallererst möchte ich meinen grossen Respekt für Ernst@at bekunden - ich finde es toll was du weisst und dass du dieses Wissen unermüdlich an Andere weiter gibst und ihnen so hilfst. Ich mache seit vielen Jahren etwas ähnliches in einem anderen Bereich (www.celestinecommunity.de) und weiss wieviel Freude soetwas bereitet, wie ermüdend das gleichzeitig ist, und wie schön es ist wenn "jemand" diese hilfe nicht als selbstverständlich nimmt.
Bitte lieber "Raid-Guru", nimm dich meines Problems an, ich habe kein Backup.....
Setup:
- Asus P5W DH Deluxe mit Intel Matrix Storage Manager
- FakeRaid0 (Intel Matrix Storage Treiber) mit 2x Samsung 250GB
- Separate SSD
- Win7 auf SSD, ABER: Userdata auf Raid gelegt (=> Windows bootet nicht mehr)
- aktuell GRML 4.2010 Linux gebootet vom USB Stick
- Beide Platten sind mit ddrescue auf ersatzplatten gesichert (keine Lesefehler, also kein HW-Defekt)
Achja, eines vorweg - und bitte KEINE Flames: Es gibt kein "funktionierendes" Backup, BEVOR das Ding hopps gegangen ist.
Ich versuche seit ner Woche eigenständig (&erfolglos) mein Raid0 zu reparieren, dazu kam es als ich nach einem Stromausfall einen SMART-Fehler auf der 2. RAID-Platte hatte. Da ein IMSM (Intel Maxtrix Storage Manager) Array keine Smart-Daten ausgibt, habe ich mir ein entsprechendes DOS-Tool runtergeladen und den SMART Status ausgelesen, was vermutlich dazu geführt hat dass der Superblock von der 2. HDD abgeraucht ist. Mein Problem ist dass ich mit Linux völlig im Dunklen tappe und ich mit Windows grad gar nicht hochfahren kann und auch keine RettungsCD hab.
Erste Aktion war, wie oben erwähnt die beiden Platten mit ddrescue zu sichern, was auch ohne (physikalische) Lesefehler gelang.
Leider kann ich dir auch die in den anderen "Rettungsthreads" gewünschten daten nicht als Screenshot schicken, da ich nicht wirklich weiss wie das in Linux geht und mein Dateisystem auf dem Stick sich bei jedem Runterfahren löscht.
"Eigentlich" müsste man nur den Superblock wieder ersetzen.....
Im Linux ergibt "sudo mdadm -E /dev/sdb" folgendes - das sollte doch alle wichtigen Informationen beinhalten:
PHP:
/dev/sdb:
Magic : Intel Raid ISM Cfg Sig.
Version : 1.0.00
Orig Family : 00000000
Family : d3b6341c
Generation : 00001a03
UUID : 1a4cb3e8:9ccc3eb2:b788ef5e:b7ee6be8
Checksum : dad13237 correct
MPB Sectors : 1
Disks : 2
RAID Devices : 1
Disk00 Serial : S09QJ1FL610761
State : active
Id : 00000000
Usable Size : 488392654 (232.88 GiB 250.06 GB)
[Deepthought]:
UUID : 0da4cf05:3ee482c6:163d12c6:768fb25c
RAID Level : 0
Members : 2
This Slot : 0
Array Size : 976783360 (465.77 GiB 500.11 GB)
Per Dev Size : 488391939 (232.88 GiB 250.06 GB)
Sector Offset : 0
Num Stripes : 1907780
Chunk Size : 128 KiB
Reserved : 0
Migrate State : idle
Map State : failed
Dirty State : clean
Disk01 Serial : S09QJ1FL610757:0
State : active failed
Id : ffffffff
Usable Size : 488392654 (232.88 GiB 250.06 GB)
"sudo mdadm -E /dev/sdc" ergibt folgendes
PHP:
mdadm: No md superblock detected on /dev/sdc.
"sudo dmraid -R isw_dffbjddegi_Deepthought /dev/sdc" ergibt
PHP:
ERROR: isw: wrong number of devices in RAID set "isw_dffbjddegi_Deepthought" [1/2] on /dev/sdb
Rebuild: raid0 cannot be rebuild
Einen Hexeditor habe ich in Linux auch gefunden. Die ersten Sektoren des Laufwerks /dev/sdb sehen so aus:
PHP:
00000000 33 C0 8E D0 BC 00 7C 8E C0 8E D8 BE 00 7C BF 00 3.....|......|..
00000010 06 B9 00 02 FC F3 A4 50 68 1C 06 CB FB B9 04 00 .......Ph.......
00000020 BD BE 07 80 7E 00 00 7C 0B 0F 85 0E 01 83 C5 10 ....~..|........
.... (edit: gekürzt, weil nicht wirklich relevant, siehe weiter unten) .....
Erwartungsgemäss ist dieser Bereich auf /dev/sdc "leer":
PHP:
00000000 00 A9 01 A9 02 A9 03 A9 04 A9 05 A9 06 A9 07 A9 ................
00000010 08 A9 09 A9 0A A9 0B A9 0C A9 0D A9 0E A9 0F A9 ................
00000020 10 A9 11 A9 12 A9 13 A9 14 A9 15 A9 16 A9 17 A9 ................
00000030 18 A9 19 A9 1A A9 1B A9 1C A9 1D A9 1E A9 1F A9 ................
00000040 20 A9 21 A9 22 A9 23 A9 24 A9 25 A9 26 A9 27 A9 .!.".#.$.%.&.'.
00000050 28 A9 29 A9 2A A9 2B A9 2C A9 2D A9 2E A9 2F A9 (.).*.+.,.-.../.
.... (edit: gekürzt, weil nicht wirklich relevant, siehe weiter unten) .....
Zusätzlich habe ich die Sektoren 0x1000000 auf beiden Platten ausgelesen. Ergebnis:
/dev/sdb
PHP:
01000000 67 6F 4B 43 67 6F 4B 43 67 6F 4B 43 67 59 47 42 goKCgoKCgoKCgYGB
01000010 67 6F 47 42 67 59 43 41 67 49 43 42 67 59 47 43 goGBgYCAgICBgYGC
01000020 67 59 4B 43 67 59 47 43 67 6F 4B 44 67 6F 4B 43 gYKCgYGCgoKDgoKC
01000030 67 6F 4B 43 67 34 4F 45 68 49 4F 44 67 34 4F 45 goKCg4OEhIODg4OE
.... (edit: gekürzt, weil nicht wirklich relevant, siehe weiter unten) .....
Auf /dev/sdc sieht es so aus:
PHP:
01000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
01000010 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
01000020 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 AAAAAAAAAAAAAAAA
01000030 41 41 0D 0A 41 41 41 41 41 41 41 41 41 41 41 41 AA..AAAAAAAAAAAA
.... (edit: gekürzt, weil nicht wirklich relevant, siehe weiter unten) .....
Meine Fragen
- Was brauchst du noch?
- Was soll ich tun? und ...
- Bekomme ich die Daten wieder??
Jetzt schon: DANKE!!! für deine Unterstützung
Zuletzt bearbeitet: