Ich habe hier 2 HD aus einem RAID mit dem Adaptec 2100S. Wahrscheinlich sind beide HD defekt. Mindestens im Adapter-Setup. Sind da noch Daten zu retten oder ist das sinnlos? Und wo setzt man an. Die Meldung NTLDR fehlt kommt noch. Ich werde es in einem XP-Rechner testen. Als vor einem halben Jahr der Piepser den ersten Ausfall signalisierte, hat der Heini (Minifirma) nicht eine neue HD angeschafft, sondern den Piepser abgekniffen. Und ein Image gibt es auch nicht. Leute gibt es!!
naja bei 2 Festplatte war es wohl ein Raid1 gewesen sein. Der Controller hat maximal in den vordere Bereich etwas geschrieben. Aber die Daten müssen ganz normal auf beiden Festplatte drauf sein. Einfach die Festplatte ein einen andere PC anschließen und erstmal ein image machen.
Dann such Dir einen professionellen Datenretter. Allerdings kostet das eine Stange Geld. Bevor Du aber u.U. wichtige Daten versehentlich plättest, lass besser einen Profi ran. Wenn die Daten eher unwichtig sind, dann kannst Du auch selber dran basteln. Gibt die Platte irgendwelche komischen Geräusche (quietschen) von sich, oder rattert der Lesekopf unaufhörlich rum?
Michael_ schrieb: > Als vor einem halben Jahr der Piepser den ersten Ausfall signalisierte, > > hat der Heini (Minifirma) nicht eine neue HD angeschafft, sondern den > > Piepser abgekniffen. WIE BITTE ?!?!?!? Dieser Heini gehört standesrechlich erschossen! Wenn es sich um Firmendaten handelt, würde ich mich mit einem Anwalt in Verbindung setzen und Onrack mit der Datenrettung beauftragen. > Und ein Image gibt es auch nicht. [ ] Du weisst, dass RAID kein Backup ersetzt? Chregu
Chregu schrieb: > WIE BITTE ?!?!?!? > > Dieser Heini gehört standesrechlich erschossen! Nö. Er hat nur die Rechnung des Datenrettungsunternehmens zu bezahlen.
Der ist so gut wie schon wieder pleite und ich bin die letzte Hoffnung. Die Daten liegen (hoffentlich)auf zwei anderen HD per SATA. Dazu muß aber erst wieder der Server laufen. Er weiß aber nicht mal mehr, welcher es war, Back-Office oder Server 2003 o.ä. Aber zurück zum Thema, wenn im Controller-Setup die HD als fehlerhaft markiert ist, kann man da überhaupt auf Daten zugreifen?
Chregu schrieb: > Dieser Heini gehört standesrechlich erschossen! Vor dem Todesurteil würde ich zunächst die Umstände abklären. Besteht/bestand ein Wartungsvertrag? Wer ist für die Datensicherung verantwortlich, der Dienstleister oder die Firma selbst? Wurde der Dienstleister beauftragt, die Platte zu tauschen oder hat man vielleicht aus Kostengründen nur gesagt "Stell den Lärm ab."? Zum Thema: Sofern die Platten als RAID1 verschaltet waren, lassen sie sich auch einzeln auslesen. Sofern der Controller noch i.O. ist, in einen funktionierenden PC stecken, Platte anstöpseln und schauen, was noch drauf ist. Sollte das Dateisystem Fehler haben, dann UNBEDINGT VOR jeglichen Reparaturversuchen eine sektorgetreue Kopie auf eine zweite Platte oder in ein Image anfertigen.
Icke ®. schrieb: > Sofern die Platten als RAID1 verschaltet waren, lassen sie sich auch > einzeln auslesen. Sofern der Controller noch i.O. ist, lassen sich mit jeden andere Kontroller aber auch auslesen. Bei Raid1 sind die Daten 1:1 auf der Platte gelandet, maximal mit einem Offset.
Peter II schrieb: > lassen sich mit jeden andere Kontroller aber auch auslesen. Nicht unbedingt. Bei SCSI-Controllern anderer Hersteller werden u.U. abweichende Plattengeometrien verwendet und dann funktioniert das nicht. Wenn Ersatz, dann möglichst baugleich, mindestens aber auch ein Adaptec.
Icke ®. schrieb: > Nicht unbedingt. Bei SCSI-Controllern anderer Hersteller werden u.U. > abweichende Plattengeometrien verwendet und dann funktioniert das nicht. scsi ist doch schon Blockorigentiert - der controller hat doch gar keinen einfluss auf die Goemetrie wie bei IDE.
Peter II schrieb: > scsi ist doch schon Blockorigentiert - der controller hat doch gar > keinen einfluss auf die Goemetrie wie bei IDE. Er hat keinen Einfluß auf die interne Geometrie der Platte, richtig. Aber es ist dem Controller überlassen, wie er die Blöcke mappt. Und da gibt es sehr wohl Unterschiede. Die gibt es sogar bei IDE/SATA. Bestes Beispiel sind die IBM Thinkpads, die abweichend vom Rest der Welt mit 240 statt 255 Köpfen arbeiten. Eine im Thinkpad formatierte Platte funktioniert nicht im normalen PC oder umgekehrt. Alles praktisch erlebt.
Icke ®. schrieb: > Die gibt es sogar bei IDE/SATA. Bestes > Beispiel sind die IBM Thinkpads, die abweichend vom Rest der Welt mit > 240 statt 255 Köpfen arbeiten. Eine im Thinkpad formatierte Platte > funktioniert nicht im normalen PC oder umgekehrt. Alles praktisch > erlebt. ja abende bei IDE - bei SCSI gibt es sotwas ja nicht. Bei SATA auch nicht. > Er hat keinen Einfluß auf die interne Geometrie der Platte, richtig. > Aber es ist dem Controller überlassen, wie er die Blöcke mappt. macht aber gar keinen sinn hier etwas zu mappen (habe ich auch noch nie erlebt). Warum sollte der controller reichzeit fürs mappen verschwenden? Es gibt ja keine gute oder schlechte sektoren. Jeder Sektor hat nur eine nummer. Ob er innen oder außen liegt kann die festplatte selber entscheiden.
http://www.dawicontrol.de/index.php?cmd=faqdet&id=1#a39 3. Frage von unten "Ich hatte vorher einen anderen Hostadapter in meinem Rechner"
Icke ®. schrieb: > http://www.dawicontrol.de/index.php?cmd=faqdet&id=1#a39 > > 3. Frage von unten "Ich hatte vorher einen anderen Hostadapter in meinem > Rechner" mehr macht denn ein Low-Level Format? SCSCI controller machen es zu mindest im normmal fall nicht beim einrichten einen Raids. Ich kann mir immer noch nicht vorstellen wie das überhaupt gehen soll, man kann dort nur sektornummer übergeben. Bei SCSI wird doch der festplatte das kommando zu Low-Level formatiern übergeben. Dann macht es die festplatte selber. Und egal wie die festplatte intern formatiert ist. Wenn man Sektor X haben will fordert man in einfach an und er ist da. Das einzigste was möglich ist, das der Kontroller wirklich ein Mapping macht also sektor 1 als sektor 5 an das Betriebssystem weiter gibt. Aber ich wüsste keine Grund warum er das machen sollte.
Peter II schrieb: > Ich kann mir immer noch nicht vorstellen wie das überhaupt gehen soll, Unabhängig von deiner Vorstellungskraft ist es eine praktische Tatsache, daß nach einem Controllerwechsel u.U. nicht mehr auf die Daten zugegriffen werden kann. Warum genau, kann ich dir auch nicht sagen, da mußt du die Hersteller und Treiberprogrammierer fragen, die schreiben das ja nicht ohne Grund in ihre FAQ. Mir ist es als frischgebackenem Servicetechniker selbst passiert. Novell-Server, Futuredomain-Controller raus, Adaptec rein. Zunächst scheinbar alles OK. Beim Speichern der ersten Datei Fehlermeldung und Volume korrupt. Datensicherung vorhanden, die Rücksicherung dauerte dank der damals üblichen Floppystreamer aber die halbe Nacht.
Icke ®. schrieb: > Zunächst scheinbar alles OK. > Beim Speichern der ersten Datei Fehlermeldung und Volume korrupt. also wenn das system noch bootet dann stimmem die Festplattensektoren. Oder glaubst du wirklich das nur jeder 100. Sektor anders behandelt wird.
Icke ®. schrieb: > Mir ist es als frischgebackenem > Servicetechniker selbst passiert. Wobei ich mir nicht sicher bin, ob diese Probleme heute noch aktuell sind. Die von dir beschriebenen Systeme könnten noch von der früher systemweit teilweise üblichen CHS-Adressierung geprägt sein, auch wenn das SCSI Protokoll seit jeher mit LBA arbeitete, während heute anfangend mit dem BIOS und der Partitionierung ziemlich durchgängig auch bei SATA die LBA-Adressierung vorherrscht.
Peter II schrieb: > also wenn das system noch bootet dann stimmem die Festplattensektoren. Es bootet auch, wenn Partitionsanfang, Bootsektor und Systemdateien noch da liegen, wo sie erwartet werden. Das Ende der Boot-Partition bzw. Anfang/Ende anderer Partitionen kann aber dennoch wo ganz anders sein. Novell 3.x startet von einer DOS-Partition, das Datenvolume hat eine eigene. A. K. schrieb: > Wobei ich mir nicht sicher bin, ob diese Probleme heute noch aktuell > sind. Die von dir beschriebenen Systeme könnten noch von der früher > systemweit teilweise üblichen CHS-Adressierung geprägt sein, auch wenn > das SCSI Protokoll seit jeher mit LBA arbeitete Genau. Das Blockmapping wurde schon immer (und wird noch) vom Controller-BIOS bzw. vom Treiber verwaltet. Ich habe mir seitdem jegliche Experimente verkniffen, aber da die Problematik in den aktuellen FAQ enthalten ist, scheint das Problem durchaus noch existent.
Icke ®. schrieb: > Genau. Das Blockmapping wurde schon immer (und wird noch) vom > Controller-BIOS bzw. vom Treiber verwaltet. nein ebend nicht. Es gibt kein Mapping mehr weil gar nicht mehr umgerechnet werden muss. Ich habe SCSCI platten an den verschiendensten kontroller und dabei konnte ich immer alle Daten lesen. Bei SATA Festpatte sind durch eSATA eh zu jeden PC kompatibel. Deine Problem kann also nur bei IDE und der CHS Adressesierung auftreten die aber seit viele Jahren nicht mehr verwendert wird.
Peter II schrieb: > nein ebend nicht. Es gibt kein Mapping mehr weil gar nicht mehr > umgerechnet werden muss. > > Ich habe SCSCI platten an den verschiendensten kontroller und dabei > konnte ich immer alle Daten lesen. http://www.heise.de/ct/hotline/Mapping-bei-SCSI-Platten-303570.html Kann gut sein, daß es zwischenzeitlich funktioniert. Ich würde dennoch keinen Controller eines anderen Herstellers verwenden, weil man bei Lesefehlern nicht nachvollziehen kann, ob das Problem nun von einem defekten Dateisystem oder vielleicht doch vom Controller verursacht wird. > Bei SATA Festpatte sind durch eSATA eh zu jeden PC kompatibel. > > Deine Problem kann also nur bei IDE und der CHS Adressesierung auftreten > die aber seit viele Jahren nicht mehr verwendert wird. Solange sich die Hersteller an de facto Standards halten, was fast alle tun, gibt es kein Problem. Die Thinkpads machen da eine Ausnahme. Praktisches Beispiel: Kunde möchte eine größere Festplatte. Übliches Vorgehen, neue Platte mittels USB-Adapter angesteckt, mit Acronis geklont, alte Platte raus, neue rein. Funktioniert sonst immer. Nicht im Fall eines Thinkpad R61. Gerät bootet mit der geklonten neuen Platte nicht. Nach ausgiebiger Recherche erweist sich die vom Thinkpad benutzte Geometrie mit 240 Heads als Ursache, weil bei Anschluß über den USB-Adapter mit 255 adressiert wird. Abhilfe brachte der Zwischenschritt über ein Image, also alte Platte -> Image, neue Platte rein, Image -> neue Platte. Siehe auch: http://forum.thinkpads.com/viewtopic.php?f=5&t=91802
Icke ®. schrieb: > Siehe auch: > > http://forum.thinkpads.com/viewtopic.php?f=5&t=91802 Samsung HM160HC (160GB 2.5" PATA). genau was wir gesagt haben: IDE -Festplatte, dort wurde CHS andressierung gemacht (konnte man bei einigen im Bios manuell einstellen) Bei SCSCI und SATA gibt es das aber nicht mehr.
Angehängte Dateien:
-
testdisk.jpg
89 KB
Peter II schrieb: > Icke ®. schrieb: >> Siehe auch: >> >> http://forum.thinkpads.com/viewtopic.php?f=5&t=91802 > > Samsung HM160HC (160GB 2.5" PATA). > > genau was wir gesagt haben: IDE -Festplatte, dort wurde CHS > andressierung gemacht (konnte man bei einigen im Bios manuell > einstellen) > > Bei SCSCI und SATA gibt es das aber nicht mehr. Der Link ist nur ein Beispiel. Bei dem von mir beschriebenen Fall handelte es sich um ein Thinkpad R61 mit S-ATA Platten. Im Anhang ein Screenshot von meinem R60 mit OCZ Vertex SDD (S-ATA). Auch Testdisk kommt mit den 240 Heads nicht klar, sondern erwartet 255. Das Notebook und Win7 laufen aber problemlos damit, das kann ich dir versichern. Sorry für die miese Bildqualität, Handyfoto.
dann verwendest du zu alte Tools - bei SATA gibt ein keine Heads mehr.
Peter II schrieb: > dann verwendest du zu alte Tools Testdisk V6.12, also fast neu. - bei SATA gibt ein keine Heads mehr. S-ATA an sich beschreibt zunächst nur die physikalische Schnittstelle, welche sich von parallelem Bus auf seriell Punkt-zu-Punkt geändert hat. Mit der Adressierung hat das erst mal nix zu tun. Im Gegensatz zu P-ATA kann S-ATA aber im Enhanced Mode betrieben werden, wodurch es sich gegenüber dem OS nicht als ATAPI-Device, sondern ähnlich wie SCSI als Massenspeicher-Controller zu erkennen gibt. Im Compatible-Mode verhält es sich wie ein klassisches IDE-Device. Irgendetwas ist bei den Thinkpads definitiv anders, denn sowohl das R61 als auch mein R60 sind auf AHCI eingestellt. Das Phänomen ist mit bisher auch ausschließlich bei Thinkpads untergekommen.
Icke ®. schrieb: > Testdisk V6.12, also fast neu. kann schon sein, kenn ich nicht. ich verwende immer die Tool der hersteller (gibt ja zum glück nicht so viele) Und nur diesen Tools traue ich über den weg. Die Festplatte ist 64Gbyte gross, also auf jeden fall kein aktuelles modell. Eventuell haben sie einen IDE-SATA adapter verbaut.
Peter II schrieb: > Die Festplatte ist 64Gbyte gross, also auf jeden fall kein aktuelles > modell. Eventuell haben sie einen IDE-SATA adapter verbaut. Die Festplatte ist eine ~1,5 Jahre alte SSD OCZ Vertex2. Sie steckt direkt in MEINEM Thinkpad R60. Typ und Größe der Festplatte spielen auch keine Rolle, mit jeder beliebigen anderen sähe es genauso aus (die neue im R61 war eine klassische 320GB Hitachi).
Icke ®. schrieb: > Die Festplatte ist eine ~1,5 Jahre alte SSD OCZ Vertex2. Sie steckt > direkt in MEINEM Thinkpad R60. Typ und Größe der Festplatte spielen auch > keine Rolle, mit jeder beliebigen anderen sähe es genauso aus (die neue > im R61 war eine klassische 320GB Hitachi). und was zeigt Linux als info für die Festplatte an? du behauptest als wenn man diese Festplatte an dem IBM mit dd ausliest andere infos bekommt als wenn man sie mit einem andere PC ausliest? nein das glaube ich immer noch nicht.
Wenn Icke nicht mit etlichen Aliasnamen in diversen Foren unterwegs ist, dann scheint seine Aussage zuzutreffen, dass Festplattenklone unabhängig vom verwendeten Programm bei Thinkpads nur dann funktionieren, wenn das Ziel des Klons im Thinkpad steckt. Immerhin ist es kein Problem, einen BIOS-Bootloader so zu schreiben, dass er nur mit 240-er Disks funktioniert. Ob das nun ein Fehler, steinzeitliche BIOS-Schnipsel oder Absicht ist darf sich jeder selber ausmalen.
Obwohl CHS-Adressierung aus der Mode gekommen ist stecken Restbestände davon bis heute in der althergebrachten Partitionierungsinformation drin. Man muss die nicht nutzen, da auch LBA-Info dort steht, aber man kann.
A. K. schrieb: > Obwohl CHS-Adressierung aus der Mode gekommen ist stecken Restbestände > davon bis heute in der althergebrachten Partitionierungsinformation > drin. dabei ist aber die umrechnung scheinbar festgelgt und nicht abhänig von der festplatte: http://de.wikipedia.org/wiki/Partitionstabelle Da bei modernen Festplatten die Adressierung durch CHS (255 Heads × 63 Sektoren × 1024 Zylinder × 512 Bytes = ca. 8 GiB) nicht ausreicht, wird ab dieser Größe immer 254, 63 und 1023 für die CHS-Werte angegeben und Position und Größe werden dann ausschließlich durch die Sektorangaben festgelt
Was aber, wenn sich Lenovo/IBM nicht an diese Konvention gehalten haben?
A. K. schrieb: > Was aber, wenn sich Lenovo/IBM daran nicht an diese Regel gehalten > haben? dann ist das gerät fehlerhaft und ein ein sonderfall -> zurück zum hersteller.
Wo ist diese Konvention so festgeschrieben, dass daraus ein Rechtsanspruch des Kunden entsteht? Wikipedia wird dazu kaum ausreichen.
A. K. schrieb: > Wo ist diese Konvention so festgeschrieben, dass daraus ein > Rechtsanspruch des Kunden entsteht? Wikipedia wird dazu kaum ausreichen. das kann ich kaum sagen, aber ich denke schon das es irgendwo beschrieben ist. Sonst könnte man den ganze eSATA zeug ja vergessse, wenn jedes Gerät die sektoren anders ausließt.
Peter II schrieb: > dann ist das gerät fehlerhaft Warum? Weil sie nicht der "Spec" des deutschen Wikipedia-Eintrags entsprechen?
Wiederum laut Wikipedia scheint Intel das in EFI reingeschrieben zu haben. Was freilich erst relevant wird, wenn der Hersteller ebendies oder UEFI auch verwendet.
A. K. schrieb: > Wiederum laut Wikipedia scheint Intel das in EFI/UEFI reingeschrieben zu > haben. Was freilich erst relevant wird, wenn der Hersteller ebendies > verwendet. es muss auch vorher schon eine SPEC gegeben haben, vermutlich dort wie sie auch die umschiffung der 128GB grenze eingebaut haben.
Die 128GB Grenze besteht zwischen LBA28 und LBA48. Die ist hier nicht relevant. Das klassische CHS war bereits bei 8GB am Ende.
A. K. schrieb: > Die 128GB Grenze besteht zwischen LBA28 und LBA48. Die ist hier nicht > relevant. aber auch das muss irgendwo definiert sein - ist da noch IBM dafür zuständig?
Sicher nicht, denn LBA kam erst mit ATA auf und damit hatte IBM nichts zu tun. In S-ATA 1.0 habe ich auf die Schnelle nichts dazu gefunden. Eine ATA Referenz von 2000 (Draft) enthält zwar einige Seiten über die CHS/LBA-Translation, schreibt aber kein bestimmtes Rechenschema vor.
Hier es es beschrieben: http://en.wikipedia.org/wiki/Logical_block_addressing#Enhanced_BIOS müsste man jetzt mal genau lesen um den schuldigen zu finden. Einer wird sich nicht daran halten.
Ich tippe eher darauf, dass eine konkrete LBA/CHS-Translation vor EFI nicht formal vorgeschrieben ist, sondern dass es sich lediglich um eine verbreitete weil naheliegende Konvention handelt.
wenn ich das richtig lese http://www.t10.org/t13/project/d1321r3-ATA-ATAPI-5.pdf dann kann man scheinbar die "default translation" der Festplatte über commandos ändern. Eventuell macht ja das Bios soetwas.
Angehängte Dateien:
-
fdisk.jpg
44 KB
Peter II schrieb: > zeigt doch mal bitte fdisk von linux von der Festplatte Bitteschön. Sorry again for poor quality.
Icke ®. schrieb: > Bitteschön. Sorry again for poor quality. Bei deinem Testdisk steht bei Head 255 da, bei linux 240. Da linux keine Fehler anzeigt wird es wohl ein Problem bei dem Testdisk sein, er ermittel die falsche anzahl von Heads.
Peter II schrieb: > Bei deinem Testdisk steht bei Head 255 da, bei linux 240. Da linux keine > Fehler anzeigt wird es wohl ein Problem bei dem Testdisk sein, er > ermittel die falsche anzahl von Heads. Sag ich doch, siehe oben. Testdisk erkennt zwar, daß da 240 Köpfe sind, hält das aber für falsch.
Icke ®. schrieb: > Sag ich doch, siehe oben. Testdisk erkennt zwar, daß da 240 Köpfe sind, > hält das aber für falsch. nein andersrum. Testdisk behauptet das die Festplatte 255 Heads hat. (CHS 7783 255 63) Laut linux hat sie aber nur 240. Auch im NTFS soll 240 stehen. Damit ist klar das alle aktionen die mit Testdisk gemacht werden fehlerhaft sind. Also scheint ja wohl Testdisk das problem zu sein.
Peter II schrieb: > nein andersrum. Testdisk behauptet das die Festplatte 255 Heads hat. > (CHS 7783 255 63) Meinetwegen. Egal wie rum, es sollte ohnehin nur als Beispiel dienen, daß die Geometrie nicht immer standardkonform sein muß. Blöd, wenn man dann Reparaturtools drüber laufen läßt, die das nicht mitkriegen.
Icke ®. schrieb: > Meinetwegen. Egal wie rum, es sollte ohnehin nur als Beispiel dienen, > daß die Geometrie nicht immer standardkonform sein muß. Blöd, wenn man > dann Reparaturtools drüber laufen läßt, die das nicht mitkriegen. laut wiki scheint nur 240 sogar ziemlich überlich zu sein. Quellcode ist doch da, finde doch mal raus wie er auf 255 kommt.
Peter II schrieb: > Jörg Wunsch schrieb: >> Und real vermutlich nur 2. :-) > > Nee 0 - ist eine SSD 5 Punkte für dich. ;-)
Toller screenshot von fdisk. Kann man das nicht in eine Datei umleiten?
huz schrieb: > Toller screenshot von fdisk. > Kann man das nicht in eine Datei umleiten? 'türlich kann man. Da hätte ich in der live-Shell aber erst wieder einen Stick mounten und mir die Syntaxen man-en müssen usw. =:P
> 'türlich kann man. Da hätte ich in der live-Shell aber erst wieder einen > Stick mounten und mir die Syntaxen man-en müssen usw. =:P Wozu brauchst du für eine Umlenkung mit ">" in eine Datei eine man-page? Sorry. Klingt nach fauler Ausrede.
abc schrieb: > Wozu brauchst du für eine Umlenkung mit ">" in eine Datei eine man-page? Wie leitet man innerhalb von fdisk die mit "p" erzeugte Ausgabe in eine Datei um? Reicht da ein simples ">"? Wie ist die korrekte Syntax, um in der Shell einen USB-Stick writeable zu mounten (Linux von einfacher Debian CD gestartet, kein GUI)? Wenn man nicht jeden Tag mit Linux umgeht, muß man schon in die man-Files schauen. Und nein, ich werde mich dafür weder schämen, noch rechtfertigen.
Icke ®. schrieb: > Wie leitet man innerhalb von fdisk die mit "p" erzeugte Ausgabe in eine > Datei um? Reicht da ein simples ">"? sfdisk -Ggl /dev/unsinn >suchsesdiraus -G: Geometrie aus Partitionstabelle -g: Geometrie laut Kernel -l: Partitionstabelle > Wie ist die korrekte Syntax, um in der Shell einen USB-Stick writeable > zu mounten (Linux von einfacher Debian CD gestartet, kein GUI)? Nicht partitionierter Stick: mount /dev/sde /mnt Partitionierter Stick: mount /dev/sde1 /mnt
Danke. Um das herauszufinden, hätte ich bestimmt 10 Minuten gebraucht. Abfotografiert wars in einer.
Icke ®. schrieb: > Danke. Um das herauszufinden, hätte ich bestimmt 10 Minuten gebraucht. Merk dir fürs nächste Mal das T-Stück: "tee".
1 | fdisk | tee logfile |
Danach kannst du dein fdisk ganz normal interaktiv bedienen, aber das T-Stück zweigt vom Rohr (also der Pipe) noch eine Kopie nach "logfile" ab.
Mal zum Zwischenstand. Es ist nicht so hoffnungslos, wie es am Anfang aussah. Ich habe ein XP-Pro neu aufgesetzt und den Kontroller mit den zwei HD eingebaut. Zusätzlich habe ich Paragon Suite 2012 installiert. Leider konnte ich die HD nicht kopieren, da sie "gesperrt" waren. Also habe ich einen Adaptec 29160 eingebaut und die HD einzeln eingebaut und je auf eine andere HD kopieren können. Leider mit einigen Inkonsistensen. Das BS konnte ich auch auslesen, es ist Server 2003 Enterprise SP2. Grundsätzlich konnte ich auch starten, aber auf Grund der anderen Hardware blieb es dann hängen. Morgen werde ich mich wieder zu dem Server begeben und mit den kopierten HD sehen, was man machen kann. Mit einer Reparaturinstallation wird es sicher gehen. Komisch ist aber, das die eine HD am Originalkontroller einen starken Pfeifton von sich gab, am 29160 jedoch nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.