3TB Festplatte wird als "nicht zegeordnet" erkannt..verdammt

[photom]

3TB Festplatte wird als "Nicht Zugeordnet" erkannt..verdammt

Hallo Freunde,

in den letzten Tagen habe ich 8 Stück neue 3gb Festplatten gekauft und mein System inkl. NAS umgestellt.
Leider ist mir heute was passiert. Ich habe 3TB daten von einer 3TB auf die andere Platte verschoben (STRG + X) und habe den PC den ganzen Tag arbeiten lassen.
Als ich zurück gekommen bin hat er die Festplatte, auf welche die Files verschoben worden sind (WD 3TB) nicht mehr erkannt.
In der Datenträgerverwaltung steht "Nicht Initialisiert bzw. Nicht zugeordnet"
Diese Daten habe ich leider noch nicht gesichert.
Mit GetDataBack kann ich die Daten von der einen 3TB oder von der anderen 3TB (gleiches Model) sicher noch retten (?) aber geht es nicht auch irgenwie anders?!
Was wird kaputt sein? Diese Tabelle oder?!

Die Festplatten sind beide GPT und die andere geht ganz normal

Vielen Dank Tom!!!

http://photom.at/tempf/hd-hin.jpg

 

[Biggunkief]

Hast du mal Testdisk drüber laufen lassen?

 

[photom]

Hallo,
ich muss auch sagen dass ich micht sooo gut auskenne
habe TESTDISK runtergeladen und bin mal so weit
siehe screenshot

EDIT: 20 min später bin ich auf 5% wird also noch 95 mal 4 Minuten dauern. Soll ich dann wieder einen screenshot posten?!

http://photom.at/tempf/hd-hin2.jpg

 

[Ernst@at]

Hallo Tom, so liest man sich wieder...

Begriffsdefinition: Dateien/Ordner wurden vom Quell-Laufwerk zum Ziel-Laufwerk per Strg+X/Strg+V verschoben, d.h. am Quelllaufwerk gelöscht

Benötigte Information zur Ursachenfeststellung:
- Installier die Trial-Version von HD Sentinel, erzeuge einen Report
(nach Aufruf im Menü/Report/Save Html Report...), und stell den gezippt in den Anhang.
- Welchen Laufwerksbuchstaben hat das Quelllaufwerk?
- welche Datenmenge wurde verschoben, wieviel war vor Beginn der Verschiebeoperation schon am Ziellaufwerk belegt?
- ist das Ziellaufwerk in einem ext.Gehäuse? Wenn ja, in welchem? Anschluss per eSATA/USB2.0/USB3.0 ?
- Mainboard-Type, BIOS-Version (noch die gleiche wie früher?)
- momentane Treiberversion(Anweisung zur Ermittlung erfolgt im nächsten Schritt)

Vorgangsweise:

- solange nicht abgeklärt ist, wodurch der Zugriffsverlust am Ziellaufwerk zustande gekommen ist, muss davon ausgegangen werden, dass vom Ziellaufwerk die Daten nicht mehr rekonstruiert werden können.

- Wenn Dateien größer 4GiB verschoben wurden, sind diese nach Löschung von keinem Datenrettungstool am Quelllaufwerk mehr auffindbar(werden als Dateien mit 0 Bytes Größe erkannt), in diesem Falle sollte der Zugriff durch Windows unterbunden werden (durch Entfernen des Laufwerkbuchstabens via Datenträgerverwaltung).

- andernfalls dürfen auf das Quelllaufwerk keine Schreiboperationen durchgeführt werden, weil dadurch Verzeichniseinträge der gelöschten Dateien und Daten überschrieben werden.

Ob der Einsatz von Testdisk was bringt, kann ich nicht sagen. Hab bisher keine vernünftige Wiederherstellung auf GPT initialisierten Datenträgern hier mitbekommen(kann mir aber durchaus entgangen sein). Außerdem scheint die Version 6.12 nicht die neueste zu sein.

Eine Überprüfung, welche der am Quelllaufwerk gelöschten Dateien gerettet werden können, lässt sich mit GetDataBack durchführen. Dateien >4GiB werden mit 0 Bytes ausgewiesen und können günstigstenfalls in Handarbeit gerettet werden.

Ob Daten vom Ziellaufwerk gerettet werden können, hängt von der Ursache der Zerstörung ab. Diese kann per GetDataBack+HxD ermittelt werden.
Unter Umständen sind nur noch Informationen der im letzten Kopiervorgang übertragenen Dateien vorhanden, aber jene der Dateien, welche schon davor drauf waren, weg.

 

[photom]

Hallo
hehe ja
belegt war schon ca 1.5 TB
Verschoben wurde ca 1 TB
Das Quallaufwerk wurde schon entfernt. K.A. welchen buschstaben es hatte
Kein Externes gehäuse...Quellaufwerk war exteren Dockingstation per USB und ziellaufwerk war externe Dockingstation per eSATA
Qualllaufwerk wird natürlich nicht mehr beschrieben

Hier ist der Diskreport
http://photom.at/tempf/Disk_report_2012_04_23.html

und Hier Testdisk screenshot...was nun?!
load?

http://photom.at/tempf/hd-hin3.jpg

Ergänzung (23. April 2012)

aja habe die neue version installiert (6.14 ist nur beta habe als 6.13 genommen)
und lasse gerade noch einen test durchlaufen. (die 6.12 ist aber noch offen)

 

[fritte76]

Hier stand Unsinn

 

[Ernst@at]

Ich hab mir mal den SMART-Bericht angesehen.
Als Fehlerquelle des >2TB Bugs kommt in Frage
- Mainboard (fällt nach Sichtung der Plattenbefüllung weg)
- Treiber (fällt nach Sichtung der Plattenbefüllung weg)
- Ext.Case/ Dockingstation
Somit wäre zu befürchten, dass die verwendete Dockingstation entweder mit alter Firmware betrieben oder überhaupt nicht in der Lage ist, mit Platten >2TiB zu arbeiten.
Welches Fabrikat/Modell der Dockingstation hast Du da verwendet?

Das Indiz, es waren schon ca 1,5TB drauf und es wurden weitere 1TB rübergeschoben (und damit die 2TiB Grenze überschritten) ist schon recht gewichtig.
Wenn die Dockingstation das nicht unterstützt, wird bei überschreiten der 2TiB Grenze einfach wieder vorne auf die Platte draufgeschrieben, bis erst der Partitionbeginn und recht bald dann auch das Inhaltsverzeichnis überschrieben wird. Zurückgeschrieben werden dann an die ursprünglich vorgesehenen Stellen des Inhaltsverzeichnisses nur die neuen Einträge.

Ob das so ist, lässt sich mit GetDataBack nach einem Komplettscan feststellen, wo dann nur die neuen Dateien gefunden werden.

per HxD kann man die Zerstörung des Verzeichnisses, der $MFT, viel schneller nachweisen.

Erstmal die GPT Informationen zum Feststellen der Partitionposition
Dazu lass die Zielplatte in der Dockingstation per eSATA

Installier dir, falls nicht vom letzten Mal noch vorhanden, HxD von hier in der englischen Version. Nicht damit herumspielen, damit die Standardeinstellungen erhalten bleiben.

Spoiler: MBR/GPT Infos auslesen

HxD Aufruf unter User mit Administratorrechten
Im HxD ist die physical disk # um 1 größer als die Datenträgernummer in der Datenträgerverwaltung. Wenn das dort immer noch Datenträger 9 ist, dann physical disk 10 auswählen

- Menü: Extras/open disk/physical disk/hard disk x (Häkchen bei "open as readonly" NICHT entfernen)

========= extrahieren Sektor 0-32
- Menü: Edit/select block/start-offset: 0 , length: 4000, hex, OK
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Menü: File/New (es erscheint in der Anzeige ein zweiter Reiter "untitled1")
- unbedingt 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 maxLBA-33- 2TiB GPT Mirr if 2TiB bug
- auf Reiter "harddisk x" klicken
- in der Menüzeile rechts mit copy&paste in das Sector: Eingabefeld den Wert 1565565839 übertragen und Enter um dorthin zu positionieren
- Menü: Edit/select block/(den eingetragenen Start-Offset belassen) length: 4200, hex, OK
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken - aber nicht in die Anzeige!
- 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-33 GPT Mirr?
- auf Reiter "harddisk x" klicken
- in der Menüzeile rechts mit copy&paste in das Sector: Eingabefeld den Wert 5860533135 übertragen und Enter um dorthin zu positionieren
- Menü: Edit/select block/(den eingetragenen Start-Offset belassen) length: 4200, hex, OK
- Menü: Edit/copy as.../ editor view (überträgt den markierten Inhalt in die Zwischenablage)
- Reiter "untitled1" anklicken - aber nicht in die Anzeige!
- 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 "harddiskx.txt" /speichern
- HxD beenden

Den .txt File gezippt in den Anhang stellen(Antworten - Erweitert - Anhänge verwalten..), und auf weitere Anweisungen warten

 

[photom]

Hallo Ernst@at

also
gehäuse ist dieses. http://geizhals.at/440346
benutze ich schon lange...zu dem Zeitunpunkt war das Quellaufwerk als eSATA und das ziellaufwerk als usb2 (daran wird wohl das Problem liegen? bei esata funktionierts weil es nicht über den kontroller sondern direkt rennt oder?)
Er hat auch nicht die ganze dateien übertragen sonder dann ca. bei der 1/2 abgebrochen (roter balken)

Mit der neueren Version sieht es genau so aus wie mit der alten
http://photom.at/tempf/hd-hin5.jpg

deine Angaben habe ich befolgt und hier ist die Datei
http://photom.at/tempf/harddisk5.zip

werde jetzt noch get data back drüber laufen lassen.

 

[photom]

aja....10er laufwerk gibts bei mir nicht
habe nummer 5 ausgewählt siehe
http://photom.at/tempf/hd-hin6.jpg

 

[photom]

Nachtrag

Getdataback folgendes ergebnis
http://photom.at/tempf/hd-hin7.jpg

Nun lasse ich es auf den ersten Punkt laufen und schauen wir mal was nach 6 Stunden rauskommt
http://photom.at/tempf/hd-hin8.jpg

 

[Ernst@at]

Nicht vergessen, im Schritt 3 und Schritt 2 die Scanläufe zu speichern
(Menü Datei/Datenrettung speichern...)

Wie in dem Ergebnis zu sehen, ist so wie in einigen anderen bisher hier aufgetauchten Fällen die $MFT überschrieben worden. Somit können von hier bloss noch die in den nicht benannten [] Ordnern vorgefundenen Dateien des letzten Übertragungsvorganges (und auch die nur zum Teil beschädigt) von dieser Platte rückgewonnen werden.

Wie viele Daten, die zuerst auf diese leere Platte aufgebracht wurden, schon mengenmäßig durch die Umleitung an den Anfang überschrieben wurden, kann ich erst nach genauerer Analyse sagen, soferne für diese "alten" Inhalte auch kein Backup vorhanden ist. Alle anderen bis zur 2TiB Grenze übertragenen von früher und diesem Kopiervorgang sind mit Getdataback nicht mehr namensmäßig nennbar und deren Position kann auch nicht mehr bestimmt werden.
Scanprogramme wie Recuva, welche sich an signifikanten Beginnsequenzen orientieren, können Bilder und einige andere Filetypen, soferne die Dateien nicht fragmentiert waren, ohne den ursprünglich vergebenen Namen auffinden und retten.

Die im letzten Verschiebevorgang von der Quellplatte übertragenen und dabei gelöschten Dateien müssten aber (mit Einschränkung <4GB Dateigröße, welche nur in einer händischen Spezialbehandlung uU lokalisiert werden können) per GetDataBack noch mit Option "gelöschte Dateien retten" von der Quellplatte gerettet werden können.

Ergänzung (24. April 2012)

Hier die Analyse des GPT-Mirrors am Ende der Zielplatte:

Spoiler: GPTMirr Information

Analyzing: \\Pc10\shareddocs\Photom 3TB damage\harddisk5.txt

===== MBR INFORMATION ===== at LBA=0
000000001FE 8620 Boot signature='8620'... INVALID !!!
. ... Partition Table entry 1 ... INVALID !!!
. ... Partition Table entry 2 ... INVALID !!!
. ... Partition Table entry 3 ... INVALID !!!
. ... Partition Table entry 4 ... INVALID !!!

===== GPTMirr INFORMATION ===== (at LBA= 5860533167) 512
. Header info
2BAA1475E00 4546492050415254 Signature: 'EFI PART'
2BAA1475E08 00000100 Version: 1.0
2BAA1475E0C 5C000000 Hdrlength: 92
2BAA1475E10 8B1CAE39 Header CRC32: crc verification not yet coded
2BAA1475E14 00000000 (reserved)
2BAA1475E18 AFA3505D01000000 current LBA: 5860533167
2BAA1475E20 0100000000000000 backup LBA: 1
2BAA1475E28 2200000000000000 firstuse LBA: 34
2BAA1475E30 8EA3505D01000000 lastuse LBA: 5860533134
2BAA1475E38 F72D40F962DFF745 . Disk
2BAA1475E40 9B2A971B8F04B782 .. GUID: F9402DF7-DF62-45F7-9B2A-971B8F04B782
2BAA1475E48 8FA3505D01000000 PE start LBA: 5860533135
2BAA1475E50 80000000 Number of PEs: 128
2BAA1475E54 80000000 Size of PE: 128
2BAA1475E58 C601A5BA PE CRC32: crc verification not yet coded
2BAA1475E5C 00.. start of reserved area ..
000000003FF ..45 .. end of reserved area

===== PEMirr INFORMATION ===== (start LBA= 5860533135) 512
. Partition entry 1
2BAA1471E00 16E3C9E35C0BB84D . partition type
2BAA1471E08 817DF92DF00215AE .. GUID: E3C9E316-0B5C-4DB8-817D-F92DF00215AE
2BAA1471E10 893AD356AB41A14C . unique partition
2BAA1471E18 9E8B4A34160693F3 .. GUID: 56D33A89-41AB-4CA1-9E8B-4A34160693F3
2BAA1471E20 2200000000000000 Part first LBA: 34
2BAA1471E28 2100040000000000 Part last LBA: 262177 0.13GiB
2BAA1471E30 0000000000000000 Attribute flags:
2BAA1471E38 4D00690063007200 . Partition Name:
2BAA1471E40 6F0073006F006600 ..
2BAA1471E48 7400200072006500 ...
2BAA1471E50 7300650072007600 ....
2BAA1471E58 6500640020007000 .....
2BAA1471E60 6100720074006900 ......
2BAA1471E68 740069006F006E00 .......
2BAA1471E70 0000000000000000 ........
2BAA1471E78 0000000000000000 .........'Microsoft reserved partition........'
. Partition entry 2
2BAA1471E80 A2A0D0EBE5B93344 . partition type
2BAA1471E88 87C068B6B72699C7 .. GUID: EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
2BAA1471E90 05F99CA8C9892B45 . unique partition
2BAA1471E98 BBA99208801A04F3 .. GUID: A89CF905-89C9-452B-BBA9-9208801A04F3
2BAA1471EA0 0008040000000000 Part first LBA: 264192
2BAA1471EA8 FF9F505D01000000 Part last LBA: 5860532223 2794.39GiB
2BAA1471EB0 0000000000000000 Attribute flags:
2BAA1471EB8 4200610073006900 . Partition Name:
2BAA1471EC0 6300200064006100 ..
2BAA1471EC8 7400610020007000 ...
2BAA1471ED0 6100720074006900 ....
2BAA1471ED8 740069006F006E00 .....
2BAA1471EE0 0000000000000000 ......
2BAA1471EE8 0000000000000000 .......
2BAA1471EF0 0000000000000000 ........
2BAA1471EF8 0000000000000000 .........'Basic data partition................'
. Partition entry 3 - 128 *** unused ***

Die Zielplatte zeigt jetzt bei der Erstellung der Analysedaten keinen 2TiB Bug.
Hast Du die jetzt zur Analyse über ein anderes Interface angeschlossen

Anmerkung: Zum Retten dieser oben angezeigten Daten in den [] Ordnern mit Getdataback muss die Platte wieder an das Interface mit dem 2TiB Bug, falls dies erforderlich sein sollte

Bevor ich's vergesse: Deine SSD zeigt anhand des HD Sentinel-Auszuges im Win deaktivierte TRIM-Funktion, was sich im Laufe der Zeit mit Performanceverschlechterung bemerkbar macht. Scheinen nicht die neuesten Intel RST-Treiber draufzusein

Nächster Analyseschritt von der zerstörten Zielplatte:

Spoiler: Extrahieren NTFS BootMirr

HxD Aufruf unter User mit Administratorrechten (oder per rechtklick - Ausführen als ...)
- Hard disk x ist um 1 größer als die Datenrägernummer in der Datenträgerverwaltung
- Menü: Extras/open disk/physical disk/hard disk x (Häkchen bei "open as readonly" nicht entfernen)

- Eingabe mit copy&paste in das Sektoreingabefeld der Menüzeile den Wert 5860532223 und Enter

dort sollte am Beginn des Sektors in der rechten Spalte
...... EB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 ëR.NTFS .....
zu finden sein

========= Extrahieren BootMirr zur Analyse
- Menü: Edit/select block/start-offset: (eingetragenen Wert belassen) , length: 200 , hex, OK
- Edit/Copy as.../Editor View (kopiert in die Zwischenablage)
- Menü: File/New (es erscheint in der Anzeige ein zweiter Reiter "untitled1")
- in der Anzeige in das kleine punktierte Rechteck rechts unterhalb von ... 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 "BootMirr.txt" /speichern

-HxD beenden
BootMirr.txt gezippt in den Anhang

 

[photom]

Hallo ernst!
die daten waren eh nicht so extrem wichtig. das waren paar archivfotos von den Kunden aus dem Fotostudio vom jahr 2003 und 2004 und paar filme. also eh nicht sooooo extrem wichtig.
Die wirklich wichtigen daten wie werbefotoshootings usw sind extra gesichert. Und das sogar auf festplatten in einem anderen gebäude. Falls es hier mal abbrennt

andere frage. kann ich die noch vom quelllaufwerk retten?

ja festplatte steckt jetzt direkt am SATA

 

[Ernst@at]

Und das sogar auf festplatten in einem anderen gebäude. Falls es hier mal abbrennt

andere frage. kann ich die noch vom quelllaufwerk retten?

Wie sich zeigt, hast Du dazugelernt.
ich schrieb ja schon oben (allerding etwas missverständlich, hier korrigiert:
Die im letzten Verschiebevorgang von der Quellplatte übertragenen und dabei gelöschten Dateien müssten aber (mit Einschränkung <4GB Dateigröße, welche größere können nur in einer händischen Spezialbehandlung uU lokalisiert werden können) per GetDataBack noch mit Option "gelöschte Dateien retten" von der Quellplatte gerettet werden können.


Korrektur aus Post#7
- Treiber (fällt nach Sichtung der Plattenbefüllung am ICH weg)
Kann es sein, dass du per eSATA über den JMB36x arbeitest - da wären Treiber ebenfalls als Ursache möglich

 

[photom]

hey weiss nicht ob es ein JMB36x ist.
habe jetzt auf jeden fall alle alten kleinen daten vo nden quelllaufwerk wiederhergestellt. ohne problem
mit getdataback.
Nur die filme die über 4gb haben gehen nicht...aber das ist eh egal..die kann ich wieder von den DVDs sichern

 

[Ernst@at]

Dann sind ja mal die Daten im Trockenen.
Bleibt nur die Beseitigung der Ursache,
Dein Board hat 6 Intel, 2 marvell 6Gb/s und 2 JMicron Anschlüsse.
- die 3TB Zielplatte jetzt intern neu initialisieren/partititionieren.
- Anschluss per eSata und per USB Dockingstation probieren:

wenn im HxD bei Anzeige von Sektor 1 oder Sektor 5860533167 der Text "EFI PART" aufscheint, kann daraus noch nichts geschlossen werden - das sind die üblichen Adressen.
erscheint diese Anzeige aber auch auf Sektor 1565565871 und/oder auf Sektor 4294967297 , dann wird die Platte fehlerhaft addressiert.

 

[photom]

asooooo das meinst...naja habe jetzt eh alle daten mindestens 2mal gesichert und die wichtigen 3mal. Werde ich jetzt immer machen...auch beim systemwechsel dass ich auch beim verschieben die Daten trotzdem gesichert habe!!!

 

[Ernst@at]

In der Raidsonic-Beschreibung unter technische Daten zu finden:

Festplattenkapazität: 2,5": 1x bis zu 500 GB, 3,5": 1x bis zu 2 TB

Firmwareupdate gibt es nicht. Also groß draufschreiben: KEINE PLATTEN ÜBER 2TB EINSTECKEN

 

[photom]

Hey ja gilt aber nur für USB nicht für esata?

 

[Ernst@at]

Wenn der eSATA-Anschluss direkt durchgeschaltet und nicht vom bridge-chip gesteuert wird, sollte das nicht passieren. Geht aber aus der Beschreibung nicht hervor - daher mein Vorschlag zum Test siehe oben.
Der sollte nur mit einer leeren 3TB Platte gemacht werden, bei bereits befüllten wird ein Bereich von 33 Sektoren (aber an unsensibler Stelle) zerstört, womit möglicherweise der Inhalt einer oder mehrere an diesem Platz liegende Dateien verändert werden.

 

[photom]

Oke den Test mach ich morgen...sag...andere Frage...warum können eigentlich nicht Dateien mit über 4Gb gerettet werden??
LG
Tom