15187
Mar 16, 2008, updated at Mar 18, 2008 (UTC)
12899
5
0
Raid 5 verliert MBR - Daten noch da, aber RAW-Dateisystem
Ich benötige Hilfe bei der Wiederherstellung des MBR auf einem Raid5-Verbund, es handelt sich dabei um die System-Partition eines Windows 2003 Servers
Hi@all,
Vermutlich hat ein defektes Stromkabel zum Ausfall einer von drei SATA-Platten in einem Raid5 geführt. Leider ist der Controller nicht in der Lage, das System weiterhin am Laufen zu halten. Nach einem Reboot fehlte dann auch zunächst die dritte Platte. Nach Austausch des Stromkabels wurden alle 3 Platten wieder erkannt, ich habe das Raid neu angelegt, und Windows bootete bis zu einem gewissen Punkt.
Alle Versuche, in irgendwelche Herstellungsmodi zu booten, scheitern. Eine Reparatur ist auch nicht möglich.
Genialerweise liegt noch ein Backup auf einer neuen Platte (mit ntbackup erstellt). Nur wurde diese ebenfalls vom System gekillt. Diese Platte wird gerade mal noch vom Controller her mit Namen erkannt, aber Laufwerksgeometrie und Informationen dergleichen sind nicht mehr abrufbar - geschweigedem in Windows sichtbar. Die Platte wird also auch nicht mehr als Platte erkannt. Somit ist das Backup gleich mit weg...
Zurück zum Raid. Da es sich um die Systempartition eines Servers mit Active Directory und Exchange handelt, wäre es wichtig, dass die MFT wieder korrekt hergestellt wird.
Wie gehe ich das mit möglichst geringen finanziellen Mitteln an? Datenrettungssoftware, die mir die Dateien wiederbringen, nutzen nichts, wegen Active Directory und Exchange - ich benötige die volle Platte!
Kann mir jemand helfen, ohne dabei auf die Google-Suche zu verweisen? Dort findet man nämlich fast nur noch Foren, in den auf diese Suche hingewiesen wird, aber gescheite Antworten sind rar und beziehen sich immer nur auf Single-Disks.
Bin für jede Hilfe dankbar,
Gruß,
tc
Vermutlich hat ein defektes Stromkabel zum Ausfall einer von drei SATA-Platten in einem Raid5 geführt. Leider ist der Controller nicht in der Lage, das System weiterhin am Laufen zu halten. Nach einem Reboot fehlte dann auch zunächst die dritte Platte. Nach Austausch des Stromkabels wurden alle 3 Platten wieder erkannt, ich habe das Raid neu angelegt, und Windows bootete bis zu einem gewissen Punkt.
Alle Versuche, in irgendwelche Herstellungsmodi zu booten, scheitern. Eine Reparatur ist auch nicht möglich.
Genialerweise liegt noch ein Backup auf einer neuen Platte (mit ntbackup erstellt). Nur wurde diese ebenfalls vom System gekillt. Diese Platte wird gerade mal noch vom Controller her mit Namen erkannt, aber Laufwerksgeometrie und Informationen dergleichen sind nicht mehr abrufbar - geschweigedem in Windows sichtbar. Die Platte wird also auch nicht mehr als Platte erkannt. Somit ist das Backup gleich mit weg...
Zurück zum Raid. Da es sich um die Systempartition eines Servers mit Active Directory und Exchange handelt, wäre es wichtig, dass die MFT wieder korrekt hergestellt wird.
Wie gehe ich das mit möglichst geringen finanziellen Mitteln an? Datenrettungssoftware, die mir die Dateien wiederbringen, nutzen nichts, wegen Active Directory und Exchange - ich benötige die volle Platte!
Kann mir jemand helfen, ohne dabei auf die Google-Suche zu verweisen? Dort findet man nämlich fast nur noch Foren, in den auf diese Suche hingewiesen wird, aber gescheite Antworten sind rar und beziehen sich immer nur auf Single-Disks.
Bin für jede Hilfe dankbar,
Gruß,
tc
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 83251
Url: https://administrator.de/contentid/83251
Printed on: April 19, 2024 at 16:04 o'clock
5 Comments
Latest comment
fassen wir mal zusammen:
1) du hast ein raid, das ok ist, aber ohne partitionstabelle
2) du hast EINE backup platte, ebenfalls ohne partitionstabelle
als erstes würde ich von allen platten eine 1:1 kopie machen, z.b. mit acronis (alle sektoren kopieren) oder linux "DD" befehl. mit den plattenkopien kann man dann rumexperimentieren.
zur reparatur der partitionstabelle empfilt sich TESTDISK
http://www.computerbase.de/downloads/software/systemprogramme/festplatt ...
anleitung gibts hier:
http://www.computerbase.de/forum/showthread.php?t=110869
1) du hast ein raid, das ok ist, aber ohne partitionstabelle
2) du hast EINE backup platte, ebenfalls ohne partitionstabelle
als erstes würde ich von allen platten eine 1:1 kopie machen, z.b. mit acronis (alle sektoren kopieren) oder linux "DD" befehl. mit den plattenkopien kann man dann rumexperimentieren.
zur reparatur der partitionstabelle empfilt sich TESTDISK
http://www.computerbase.de/downloads/software/systemprogramme/festplatt ...
anleitung gibts hier:
http://www.computerbase.de/forum/showthread.php?t=110869
wie hast du denn das raid wieder neu angelegt? Normalerweise sollte man, wenn soetwas passiert das RAID nicht mehr anfassen bis man absolut sicher ist wo der Fehler liegt (2 defekte Platten, stromversorgung usw.)
Zum Problem:
Priorität liegt auf der Sicherungsplatte die nicht im RAID war. Ich vermute, die Platte war im Controller als single Disk an das OS durchgeschleift. Der Controller schreibt dann in den vorderen Bereich der Platte seine Infos und legt die eigentlichen Datenbereiche dahinter ab. wenn du herausfindest wie groß dieser Bereich ist, hast du fast schon gewonnen.
So kannst du dann die Platte von den Controller-infos befreien indem du unter Linux eine neue, saubere Partitionstabelle anlegst und die Partition mit dem richtigem offset einträgst (so befreie ich zb. Platten von solchen controller-infos). Anschließend sollte die Platte unter Windows wieder erkannt werden. Eventuell hast du aber auch Glück und linux erkennt die Partition direkt. Einfach mal knoppix booten und schauen ob er sie erkennt.
Hast du nicht so viel Ahnung von Partitionstabellen, sektoren usw. lass die Finger von dieser Methode. Wir haben UFS Explorer, der ist nicht so teuer und kann auch solche Laufwerke wiederherstellen. Es gibt eine Shareware-Version mit der du mal schauen kannst wie gut er die Platte erkennt.
AUF GAR KEINEN FALL versuche mit der WindowsCD ohne vorherige Analyse einfach einen neuen Boot oder MBR zu schreiben. Das würde die Daten zerstören. Sei extrem vorsichtig mit jeder Art von schreibzugriff auf die Originalplatte. Mit einem Image gehst du auf nummer sicher.
Zum Problem:
Priorität liegt auf der Sicherungsplatte die nicht im RAID war. Ich vermute, die Platte war im Controller als single Disk an das OS durchgeschleift. Der Controller schreibt dann in den vorderen Bereich der Platte seine Infos und legt die eigentlichen Datenbereiche dahinter ab. wenn du herausfindest wie groß dieser Bereich ist, hast du fast schon gewonnen.
So kannst du dann die Platte von den Controller-infos befreien indem du unter Linux eine neue, saubere Partitionstabelle anlegst und die Partition mit dem richtigem offset einträgst (so befreie ich zb. Platten von solchen controller-infos). Anschließend sollte die Platte unter Windows wieder erkannt werden. Eventuell hast du aber auch Glück und linux erkennt die Partition direkt. Einfach mal knoppix booten und schauen ob er sie erkennt.
Hast du nicht so viel Ahnung von Partitionstabellen, sektoren usw. lass die Finger von dieser Methode. Wir haben UFS Explorer, der ist nicht so teuer und kann auch solche Laufwerke wiederherstellen. Es gibt eine Shareware-Version mit der du mal schauen kannst wie gut er die Platte erkennt.
AUF GAR KEINEN FALL versuche mit der WindowsCD ohne vorherige Analyse einfach einen neuen Boot oder MBR zu schreiben. Das würde die Daten zerstören. Sei extrem vorsichtig mit jeder Art von schreibzugriff auf die Originalplatte. Mit einem Image gehst du auf nummer sicher.
Hallo Supaman,
vielen Dank für Deine schnelle Hilfe!
An Testdisk habe ich auch schon gedacht, es ist mir beim vielen Googlen mehrmals aufgefallen und genießt ja scheinbar guten Support von Fiona. Ich denke, ich folge auch Deinem Tip und werde vorab Fiona ansprechen, damit ich auf garkeinen Fall etwas falsch mache.
Ich habe nur ein Problem: wir haben zwar Acronis, aber das erkennt den Controller nicht. Ich müsste also auf eine neue Platte ein Windows spielen und von dort aus, mit installiertem Treiber, die Sektorkopie anlegen, müsste gehen, oder?
Sehe ich das so richtig:
Wir installieren ein Windows XP SP2, das auf jeden Fall auch mit Partitionen >128 GB klar kommt.
Wir installieren darauf Acronis und ziehen ein Image von dem Raid.
Dann mounten wir das Image als zusätzliches Laufwerk, nehmen das Raid auch gleich aus dem System, damit nichts versehentlich passieren kann, und an dem Image "spielen wir dann rum"?
Gruß,
poc
vielen Dank für Deine schnelle Hilfe!
An Testdisk habe ich auch schon gedacht, es ist mir beim vielen Googlen mehrmals aufgefallen und genießt ja scheinbar guten Support von Fiona. Ich denke, ich folge auch Deinem Tip und werde vorab Fiona ansprechen, damit ich auf garkeinen Fall etwas falsch mache.
Ich habe nur ein Problem: wir haben zwar Acronis, aber das erkennt den Controller nicht. Ich müsste also auf eine neue Platte ein Windows spielen und von dort aus, mit installiertem Treiber, die Sektorkopie anlegen, müsste gehen, oder?
Sehe ich das so richtig:
Wir installieren ein Windows XP SP2, das auf jeden Fall auch mit Partitionen >128 GB klar kommt.
Wir installieren darauf Acronis und ziehen ein Image von dem Raid.
Dann mounten wir das Image als zusätzliches Laufwerk, nehmen das Raid auch gleich aus dem System, damit nichts versehentlich passieren kann, und an dem Image "spielen wir dann rum"?
Gruß,
poc
Hallo datasearch,
Zur ersten Frage: Ich habe mit dem doch sehr reduzierten Boot-Rom-Raid-Manager das Raid gelöscht (etwas anderes kann der Controller nicht (es ist ein SiL 2134 oder sowas, auf jeden Fall 4xSata, PCI 32Bit, also einer der kleinsten für weniger als 40 Euro) und dann neu angelegt und dabei natürlich exakt die Einstellung der Blockgröße beachtet. In dem Fall 64K. Es war vermutlich ein Wackelkontakt in minderqualitativen Strom-Adaptern. Das Problem trat in den letzten zwei Jahren schon ca. 5-6 mal auf. Nach dem Neu-Anlegen des Raids lief es danach immer. Leider war es nicht einfach, den Einkauf davon zu überzeugen, dass dringend etwas getan werden muss. Nun soll aber ein Areca-Controller rein, sobald die Daten in irgendeiner Form greifbar sind.
Mit Linux habe ich nur oberflächliche Erfahrung, und mein Wissen über MFT beschränkt sich halt auf ein Bischen Theorie, weshalb ich auch in der Praxis nun nichts überstürzen will.
Allerdings hatte ich schon einen Schreibzugriff: FIXBOOT, es fand defekte Einträge und hat sie wieder hergestellt - natürlich erfolglos.
Gruß,
poc
PS: Ich werde mir Deinen Thread heute abend genauer ansehen und kann erst am WE testen.
Vielen Dank für Deine Hilfe.
Mit einer Sache gehe ich völlig konform: Priorität liegt an der einen Platte, die, wie Du richtig verstanden hast, am Controller als Single hängt und einfach durchgeschleift wurde. Das wäre nämlich das beste, was im Nachhinein für den Recovery-Vorgang passieren könnte. Nun stelle ich mir als Linux-Newbie die Frage: wie geht so etwas? Geht das überhaupt? Wird Linux den Controller erkennen?
Zur ersten Frage: Ich habe mit dem doch sehr reduzierten Boot-Rom-Raid-Manager das Raid gelöscht (etwas anderes kann der Controller nicht (es ist ein SiL 2134 oder sowas, auf jeden Fall 4xSata, PCI 32Bit, also einer der kleinsten für weniger als 40 Euro) und dann neu angelegt und dabei natürlich exakt die Einstellung der Blockgröße beachtet. In dem Fall 64K. Es war vermutlich ein Wackelkontakt in minderqualitativen Strom-Adaptern. Das Problem trat in den letzten zwei Jahren schon ca. 5-6 mal auf. Nach dem Neu-Anlegen des Raids lief es danach immer. Leider war es nicht einfach, den Einkauf davon zu überzeugen, dass dringend etwas getan werden muss. Nun soll aber ein Areca-Controller rein, sobald die Daten in irgendeiner Form greifbar sind.
Mit Linux habe ich nur oberflächliche Erfahrung, und mein Wissen über MFT beschränkt sich halt auf ein Bischen Theorie, weshalb ich auch in der Praxis nun nichts überstürzen will.
Allerdings hatte ich schon einen Schreibzugriff: FIXBOOT, es fand defekte Einträge und hat sie wieder hergestellt - natürlich erfolglos.
Gruß,
poc
PS: Ich werde mir Deinen Thread heute abend genauer ansehen und kann erst am WE testen.
Vielen Dank für Deine Hilfe.
Mit einer Sache gehe ich völlig konform: Priorität liegt an der einen Platte, die, wie Du richtig verstanden hast, am Controller als Single hängt und einfach durchgeschleift wurde. Das wäre nämlich das beste, was im Nachhinein für den Recovery-Vorgang passieren könnte. Nun stelle ich mir als Linux-Newbie die Frage: wie geht so etwas? Geht das überhaupt? Wird Linux den Controller erkennen?
Das ist warscheinlich das beste den controller einzumotten und durch einen richtigen zu ersetzen. Auch die Stromadaper usw. solltest du dringend ersetzen. Am besten gleich eine Backplane für die Platten, da passieren solche Fehler normalerweise nicht mehr.
Zurück zum Problem, du hast echt ein Problem wenn du fixboot schon auf die Platte geschickt hast. Das öffset findest du am besten heraus, wenn du eine leere, absolut blanke platte an den controller anschließt und durchschleifst. Anschließend die HDD an einen normalen SATA stecken und schauen was er vorn auf die Platte geschrieben hat. Sind meistens nur wenige sektoren. Anschließend bei dem erstelltem Image eine neue, leere Partitionstabelle anlegen und eine neue Partition mit dem offset X anlegen.
Blendet der Controller zb. 5 sektoren aus, must du die Partition beginnend am 5 bis zum ende anlegen. Hast du mehrere Partitionen und kein Partitionsdump von der Platte wie sie hinter dem Controller bereitgestellt wird, kannst du das auch vergessen. Rätselraten über das ende der Partition ist aussichtslos.
Alternativ kannst du die Partition direkt als loopdevice mounten. Bei offset5 kannst du mit losetup -o 5 /path/to/image/file die ersten 5 sektoren überspringen und als loopdevice bereitstellen. Abschließend versuchst du dieses loopdevice als NTFS-Dateisystem RO zu mounten. Ich habe da ein script das blockweise die offsets durchprobiert und sobald ein gültiger NTFS-Header gefunden wurde, das Dateisystem mountet (ist auch ganz nützlich bei geschredderten Partitionstabellen zb. durch Linux-Installationen).
Das ganze erfordert aber eine gewisse expermentierfreude und Erfahrung. Ich empfehle dir trotzdem das ganze mit einer Recovery-Software zu versuchen. Das Datenträger-bitmap und die MFT sollten ja, wenn du sie nicht überschrieben hast, intakt sein.
Beispiel an meiner HDD:
1. auflisten der partitionen (du müsstest den Anfang probieren)
2. Errechnen des Offsets
offset = startsektor x 512
offset = 193374405 * 512 = 99007695360
3. einbinden des Loop-devices
losetup -o OFFSET LOOPDEVICE HDD-NODE
4. Prüfen ob ein Dateisystem erkannt wurde
5. dateien kopieren und loop-device auflösen
Damit habe ich die Partition direkt gemountet. Falls kein Dateisystem gefunden wurde, gibt mount einen Fehler zurück. Das lässt sich nutzen um die offsets durchzuprobieren. Das ich am anfang die Partitionstabelle ausgelesen habe ist nur komfort. Im realen leben ist diese ja nicht mehr lesbar oder hinter einem unbekanntem Offset vesteckt.
Das hier soll dir nur als Doku bzw. Denkansatz bzw. Doku das es funktioniert dienen
wie gesagt, du musst wissen was du da machst sonst zerstörst du die Platte ehr als das du sie wiederherstellst.
Zurück zum Problem, du hast echt ein Problem wenn du fixboot schon auf die Platte geschickt hast. Das öffset findest du am besten heraus, wenn du eine leere, absolut blanke platte an den controller anschließt und durchschleifst. Anschließend die HDD an einen normalen SATA stecken und schauen was er vorn auf die Platte geschrieben hat. Sind meistens nur wenige sektoren. Anschließend bei dem erstelltem Image eine neue, leere Partitionstabelle anlegen und eine neue Partition mit dem offset X anlegen.
Blendet der Controller zb. 5 sektoren aus, must du die Partition beginnend am 5 bis zum ende anlegen. Hast du mehrere Partitionen und kein Partitionsdump von der Platte wie sie hinter dem Controller bereitgestellt wird, kannst du das auch vergessen. Rätselraten über das ende der Partition ist aussichtslos.
Alternativ kannst du die Partition direkt als loopdevice mounten. Bei offset5 kannst du mit losetup -o 5 /path/to/image/file die ersten 5 sektoren überspringen und als loopdevice bereitstellen. Abschließend versuchst du dieses loopdevice als NTFS-Dateisystem RO zu mounten. Ich habe da ein script das blockweise die offsets durchprobiert und sobald ein gültiger NTFS-Header gefunden wurde, das Dateisystem mountet (ist auch ganz nützlich bei geschredderten Partitionstabellen zb. durch Linux-Installationen).
Das ganze erfordert aber eine gewisse expermentierfreude und Erfahrung. Ich empfehle dir trotzdem das ganze mit einer Recovery-Software zu versuchen. Das Datenträger-bitmap und die MFT sollten ja, wenn du sie nicht überschrieben hast, intakt sein.
Beispiel an meiner HDD:
1. auflisten der partitionen (du müsstest den Anfang probieren)
fdisk -lu /dev/sda
Platte /dev/sda: 250.0 GByte, 250059350016 Byte
255 Köpfe, 63 Sektoren/Spuren, 30401 Zylinder, zusammen 488397168 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Disk identifier: 0xc606c606
Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 63 146496734 73248336 7 HPFS/NTFS
/dev/sda2 146496735 193374404 23438835 83 Linux
/dev/sda3 193374405 486978344 146801970 b W95 FAT32
/dev/sda4 486978345 488392064 706860 82 Linux Swap / Solaris2. Errechnen des Offsets
offset = startsektor x 512
offset = 193374405 * 512 = 99007695360
3. einbinden des Loop-devices
losetup -o OFFSET LOOPDEVICE HDD-NODE
losetup -o 99007695360 /dev/loop3 /dev/sda4. Prüfen ob ein Dateisystem erkannt wurde
mkdir tmp
mount -o ro /dev/loop3 tmp
mount /dev/loop3 tmp -vv -o ro
mount: no LABEL=, no UUID=, going to mount /dev/loop3 by path
mount: Es wurde kein Dateisystemtyp für /dev/loop/3 angegeben
Werde den Typ vfat versuchen
/dev/loop/3 on /root/tmp type vfat (ro)5. dateien kopieren und loop-device auflösen
Damit habe ich die Partition direkt gemountet. Falls kein Dateisystem gefunden wurde, gibt mount einen Fehler zurück. Das lässt sich nutzen um die offsets durchzuprobieren. Das ich am anfang die Partitionstabelle ausgelesen habe ist nur komfort. Im realen leben ist diese ja nicht mehr lesbar oder hinter einem unbekanntem Offset vesteckt.
Das hier soll dir nur als Doku bzw. Denkansatz bzw. Doku das es funktioniert dienen
wie gesagt, du musst wissen was du da machst sonst zerstörst du die Platte ehr als das du sie wiederherstellst.
