Hallo zusammen, Kurzfassung: Eine HDD wird nach dem Einbau in ein externes USB-Gehäuse (WD MyBook 3.0) nicht/teilweise erkannt. Auf der Disk ist keine Partitionstabelle mehr. Was ist kaputt? Langfassung: Eine 8TB HDD diente bis vor kurzem als Fullbackup-Archivdisk. Sie wurde gelegentlich in das freie Bay vom NAS (1x TrueNAS FreeBSD, 1x TrueNAS Debian) gestöpselt um davon ein Fullbackup zu ziehen. Die HDD-Aufteilung ist ca. 50/50. - 4TB luks, darin ein PV mit VG, mehreren LVs und Snapshot. - Rest <4TB ein exportiertes zfs-Volume. Vor wenigen Wochen löste ich die beiden NAS-Server auf und baute einen neuen. Die Daten wurden aus dem Archiv (der betroffenen Disk) wiederhergestellt. Anschließend wurde sie ins Regal verbannt. Heute wollte ich ein paar Daten wiederherstellen... Baute die HDD in ein externes Gehäuse ein und muss staunen - es kann keine Partitionstabelle gelesen werden. Ist das USB3.0-Gehäuse inkompatibel oder haben magische Strahlen die Disk vernichtet? Da ich hier und heute keinen PC habe, kann ich keinen Kreuztest machen. In dem USB-Gehäuse steckte noch gestern eine 1TB, mit welcher gearbeitet wurde. Das WD MyBook kann/soll HDDs bis 16TB aufnehmen können. Genug Prosa, in der Anlage konkretes.
4k sektoren während die 1T nur 512 byte hat? Was anderes würde mir spontan nicht einfallen.
Gerade habe ich noch ein ausrangiertes externes USB3.0 von Seagate (SRD0NF2) gefunden. Einfach trocken die HDD auf die Platinen gesteckt...
1 | [ 9380.024752] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command |
2 | [ 9380.232732] usb 4-5: new SuperSpeed USB device number 8 using xhci_hcd |
3 | [ 9380.360709] usb 4-5: new SuperSpeed USB device number 8 using xhci_hcd |
4 | [ 9380.692762] usb 4-5: new SuperSpeed USB device number 9 using xhci_hcd |
5 | [ 9380.713928] usb 4-5: New USB device found, idVendor=0bc2, idProduct=3322, bcdDevice= 1.00 |
6 | [ 9380.713941] usb 4-5: New USB device strings: Mfr=2, Product=3, SerialNumber=1 |
7 | [ 9380.713947] usb 4-5: Product: Expansion Desk |
8 | [ 9380.713951] usb 4-5: Manufacturer: Seagate |
9 | [ 9380.713954] usb 4-5: SerialNumber: 2HC015KJ |
10 | [ 9380.718714] scsi host5: uas |
11 | [ 9380.719354] scsi 5:0:0:0: Direct-Access Seagate Expansion Desk 9401 PQ: 0 ANSI: 6 |
12 | [ 9380.719991] sd 5:0:0:0: Attached scsi generic sg2 type 0 |
13 | [ 9380.720219] sd 5:0:0:0: [sdb] Spinning up disk... |
14 | [ 9381.752687] ..........ready |
15 | [ 9390.969851] sd 5:0:0:0: [sdb] 15628053167 512-byte logical blocks: (8.00 TB/7.28 TiB) |
16 | [ 9391.027223] sd 5:0:0:0: [sdb] Write Protect is off |
17 | [ 9391.027228] sd 5:0:0:0: [sdb] Mode Sense: 4f 00 00 00 |
18 | [ 9391.027446] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA |
19 | [ 9391.027657] sd 5:0:0:0: [sdb] Optimal transfer size 33553920 bytes |
20 | [ 9391.096769] GPT:Primary header thinks Alt. header is not at the end of the disk. |
21 | [ 9391.096772] GPT:15628052994 != 15628053166 |
22 | [ 9391.096775] GPT:Alternate GPT header not at the end of the disk. |
23 | [ 9391.096775] GPT:15628052994 != 15628053166 |
24 | [ 9391.096776] GPT: Use GNU Parted to correct GPT errors. |
25 | [ 9391.096784] sdb: sdb1 sdb2 sdb3 |
26 | [ 9391.097847] sd 5:0:0:0: [sdb] Attached SCSI disk |
1 | [ 9391.096769] GPT:Primary header thinks Alt. header is not at the end of the disk. |
2 | [ 9391.096772] GPT:15628052994 != 15628053166 |
3 | [ 9391.096775] GPT:Alternate GPT header not at the end of the disk. |
4 | [ 9391.096775] GPT:15628052994 != 15628053166 |
5 | [ 9391.096776] GPT: Use GNU Parted to correct GPT errors. |
Ähm, eine anschließende Frage: Was soll man sich unter primary vs. alternate header vorstellen? Außer, dass sie ein Backup sind, warum sind die nicht gleich?
Drago S. schrieb: > Eine HDD wird nach dem Einbau in ein externes USB-Gehäuse (WD MyBook > 3.0) nicht/teilweise erkannt. Auf der Disk ist keine Partitionstabelle > mehr. > Was ist kaputt? Versucht Dein Gehäuse mitzudenken und macht eine 512/4k-Emulation? Die meisten externen USB-Platten sind als MBR formatiert. Das geht eigentlich mit mehr als 2 TB nicht, daher fassen die SATA-USB-Umsetzer in den Gehäusen acht Sektoren zu einem zusammen und emulieren so 4k-Blöcke. Deine Platte ist aber als GPT mit 512 byte Blockgröße konfiguriert. Da ist die Umsetzung unerwünscht. Zu den SATA-USB-Chips gibt es meist Konfigurationstools, mit denen man die 4k-Emulation abschalten kann.
Soul E. schrieb: > 512/4k-Emulation Das macht meines Wissens die HDD von sich aus. Intern 4k, nach außen 512.
Drago S. schrieb: > steckte noch gestern eine 1TB, Kurz: Magische 2TB Grenze überschritten. Schon fängt der Ärger an. Nicht jede Kiste kommt mit größeren Platten und allen Dateisystemen gleich zurecht. https://en.wikipedia.org/wiki/GUID_Partition_Table
PC-Freak schrieb: > Das macht meines Wissens die HDD von sich aus. Intern 4k, nach außen > 512. Das gibt es auch. Hier geht es aber um den umgekehrten Fall. HDD hat 512 byte, Computer sieht am USB 4k-Blöcke. Diese Emulation wird durch den USB/SATA-Bridge-Chip der USB3.0 - Gehäuse durchgeführt.
Soul E. schrieb: > Das gibt es auch. Hier geht es aber um den umgekehrten Fall. HDD hat 512 > byte, Das glaube ich bei einer 8T Hdd nicht. Ich denke eher, dass der USB-Schnödel die HDD nicht sauber verwalten kann. Das hab ich hier auch mit einer WD60efrx und nen USB Linksys
Ja, das Gehäuse bzw. der Controller macht irgendwas. So einen Fall hatte ich bisher nicht. Ich dachte schon, dass das NAS (RAID) die 4k Blöcke weitergereicht hat. Dann fiel mir ein, dass ich manuell partioniert habe. Werde später der Sache nachgehen. Nun stehe ich vor einem Problem, mein Ubuntu ist zu doof das zfs einzuhängen. Anders gesagt, das NAS muss was abweichendes haben. Die Disk extern am NAS gesteckt wird einwandfrei gelesen. Werde wohl das Paket aus den Sourcen kompilieren und durchprobieren. Jedenfalls konnte ich die Dateien wiederherstellen. Das Backup hat sich gelohnt. Wenn nicht wie gewünscht und propagandiert - einfach zurücksichern :)
:
Bearbeitet durch User
Ich weiß nicht, warum hier über 4kB/512B schwadroniert wird. Im dmsg-Output des ersten Posts sieht man klar, dass der Controller von der Platte nichts lesen kann, es kommen nur read-errors. Ich vermute, dass der Controller die READ(16)-Kommandos (werden bei mehr als 2^32 Blöcken benötigt) nicht unterstützt. Ich Anschlußpost hängt die Platte an einem anderen Controller - der kommt damit problemlos klar - 3 Partitions, sdb1-3. Das mit dem Primary- vs Alt-Header kann passieren, wenn der Inhalt der Platte von einer (minimal) kleineren (hier 172 Blöcke) kopiert wurde. Hintergrund: GPT legt eine Kopie der Partitionstabelle auf den letzten Block der Platte. Kann man reparieren - nötig ist es nicht.
Ich würde mal versuchsweise das Programm 'testdisk' laufen lassen, erst mal nur zur Diagnose. Wenn testdisk Partitionen erkennt, ist die Wahrscheinlichkeit, dass die HD wiederbelebt werden kann, recht gut.
Hallo Drago S., Drago S. schrieb: > Kurzfassung: > Eine HDD wird nach dem Einbau in ein externes USB-Gehäuse (WD MyBook > 3.0) nicht/teilweise erkannt. Auf der Disk ist keine Partitionstabelle > mehr. > Was ist kaputt? wenn Du die Festplatte wieder am alten Ort außerhalb des verdächtigen Gehäuses (in einem Computer einbaust) und die Partitionen dann sichtbar werden, dann hat Soul E. Recht gehabt, aber dass vermute ich jetzt sowieso schon. :) Vermutlich ist gar nichts kaputt. Der Versuch des Herstellers, mit Übersetzungselektronik Festplatten über 2 TB mit einer logischen Sektorgröße (am Interface) von 512 Bytes für Altbetriebssysteme kompatibel zu machen, geht bei dem nichts ahnenden, unschuldigen Benutzer nach hinten los...
:
Bearbeitet durch User
Es ist einfach ein USB-SATA-Adapter, der nur 2TB-Platten kann (@512B). Es gibt nur eine Stelle, die überhaupt 4k erwähnt: bei der tatsächlichen physikalischen Blockgröße. An allen anderen Stellen wird mit 512B-Blöcken gearbeitet. Das Kernel sieht nirgendwo 4k-Blöcke. Die Umsetzung (durch die Platte) funktioniert! Was nicht klappt, sind die READ(16)-Kommandos (mit 64-Bit Blockadresse), die das Kernel an den USB-Adapter schickt - der meldet nur "Illegal Request", auf Deutsch "dat Kommando kann ich nicht". Das wird dann zu einem read-error. Dieser Adapter kann wohl nur READ(10)/READ(12) (mit 32-Bit Blockadresse). Das reicht aber bei dieser Platte (mit grob 2^34 Blöcken) nicht und deshalb nimmt das Kernel READ(16). Der zweite Adapter (in seinem Anschlußpost) kann READ(16) und damit klappt's dann ja auch.
foobar schrieb: > Ich weiß nicht, warum hier über 4kB/512B schwadroniert wird. > > Im dmsg-Output des ersten Posts sieht man klar, dass der Controller von > der Platte nichts lesen kann, es kommen nur read-errors. Ich vermute, > dass der Controller die READ(16)-Kommandos (werden bei mehr als 2^32 > Blöcken benötigt) nicht unterstützt. > > Ich Anschlußpost hängt die Platte an einem anderen Controller - der > kommt damit problemlos klar - 3 Partitions, sdb1-3. > > Das mit dem Primary- vs Alt-Header kann passieren, wenn der Inhalt der > Platte von einer (minimal) kleineren (hier 172 Blöcke) kopiert wurde. > > Hintergrund: GPT legt eine Kopie der Partitionstabelle auf den letzten > Block der Platte. Kann man reparieren - nötig ist es nicht. So sehe ich das auch. Zumal hier noch zu sagen ist, dass der LBA Block ganz am Anfang der Platte, nachdem MBR (aus kompatibilätsgründen), der den Primary GPT Header aufnimmt nicht mit dem Alternate GPT Header, der am letzten Block der Platte ist, übereinstimmen kann, WENN der Controller gar nicht den echten letzten LBA Block ansprechen kann, sondern als letzten Block irgendeinen irgendwo in der Mitte der Platte anspricht, weil das der letzte ist, an den er rankommt. Und wenn der Primary GPT Header und der Alternate GPT Header nicht übereinstimmen, obwohl sie das müssen, dann weiß der Kernel, dass was faul ist und meldet obigen Fehler.
Drago S. schrieb: > [ 9391.096769] GPT:Primary header thinks Alt. header is not at the > end of the disk. > [ 9391.096772] GPT:15628052994 != 15628053166 > [ 9391.096775] GPT:Alternate GPT header not at the end of the disk. > [ 9391.096775] GPT:15628052994 != 15628053166 > [ 9391.096776] GPT: Use GNU Parted to correct GPT errors. > > Ähm, eine anschließende Frage: > Was soll man sich unter primary vs. alternate header vorstellen? > Außer, dass sie ein Backup sind, warum sind die nicht gleich? Weil der Controller nicht an den letzten LBA Block rankommt und den letzten LBA Block nimmt, den er ansprechen kann und der enthält halt irgendwelche Daten, nur halt nicht den GPT Header. Es ist für diese Platte also ein Controller nötig, dessen Addressraum groß genug ist um den echten letzten LBA der Platte ansprechen zu können.
Soul E. schrieb: > Drago S. schrieb: > >> Eine HDD wird nach dem Einbau in ein externes USB-Gehäuse (WD MyBook >> 3.0) nicht/teilweise erkannt. Auf der Disk ist keine Partitionstabelle >> mehr. >> Was ist kaputt? > > Versucht Dein Gehäuse mitzudenken und macht eine 512/4k-Emulation? > > Die meisten externen USB-Platten sind als MBR formatiert. Das geht > eigentlich mit mehr als 2 TB nicht, daher fassen die SATA-USB-Umsetzer > in den Gehäusen acht Sektoren zu einem zusammen und emulieren so > 4k-Blöcke. Ich habe genau den umgekehrten Fall gehabt, allerdings ist das schon einige Jahre her. Da hatte ich eine 2TB-Platte mit 4k-Sektoren und ohne diese blödsinnige 512-Byte-Emulation. Im Rechner hat die unter Linux damals problemlos funktioniert, aber in einem USB-Gehäuse kam ich dann nicht mehr an die Daten dran, weil der USB-SATA-Wandler das auf 512-Byte-Sektoren umkonvertiert hat. Die Platte ging dort nur nach einer kompletten Neupartitionierung.
Drago S. schrieb: > Nun stehe ich vor einem Problem, mein Ubuntu ist zu doof das zfs > einzuhängen. Anders gesagt, das NAS muss was abweichendes haben. Dann schau mal was dir GParted unter Linux sagt. Ohne diesen USB-Dingsen. Direkt am Sata-Port vom Board.
Guten morgen zusammen, Thomas S. schrieb: > Dann schau mal was dir GParted unter Linux sagt. Ohne diesen > USB-Dingsen. Direkt am Sata-Port vom Board. Das geht nicht (mehr). Das NAS wurde aufgelöst und umgebaut. Der 4. Schacht (wo ehemals die Archivplatte war) beherbergt nun eine aktive 4. HDD im RAID5. Da komme ich mangels SATA-Ports nur extern über USB ran, was ich auch tat. Das erste USB-Gehäuse kam damit nicht zurecht, das zweite schon. Restore war erfolgreich. Nur der GPT am Ende wurde angemeckert. Das habe ich mit -e gefixed. Die zweite Hälfte der HDD (sdb3) beinhaltet das zfs, welches zum Schluß angehängt wurde. Auf das habe ich weiterhin keinen Zugriff, obwohl es im gleichen NAS seitens TrueNAS angelegt und betankt wurde. Ergo hat TrueNAS selbst den GPT verbockt. Sonst ist die Hardware-Spielwiese zuhause etwas eng. Habe nur noch 2 Notebooks und das aufgerüstete bzw. erweiterte neue NAS. Naja man muss auch mal den Elektrosmog reduzieren statt immer vergrôßern ;) Ich könnte es in die Arbeit mitnehmen, nur dafür habe ich tagsüber absolut keine Zeit.
:
Bearbeitet durch User
Drago S. schrieb: > Die zweite Hälfte der HDD (sdb3) beinhaltet das zfs, welches zum Schluß > angehängt wurde. Auf das habe ich weiterhin keinen Zugriff, obwohl es im > gleichen NAS angelegt und betankt wurde. So wie sich das liest, ist das ZFS ein gesamter Speicher Pool, nicht einfach nur eine Partition vom Typ ZFS. Ich würde hier folgendes versuchen: TrueNAS in eine VM installieren und dieser eine virtuelle Partition zu geben, die groß genug ist um obigen ZFS Pool zu importieren. Danach den ZFS Pool importieren und falls das klappt, die Daten durch rauskopieren auf dein neues NAS retten.
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.