
1 TB の外付けハード ディスク (Seagate) を Windows システムから直接取り外したのですが、動作しなくなりました。現在、Ubuntu で修復しようとしていますが、ディスク (gnome ユーティリティ) で確認しようとすると、メディアがないと表示されます。
私はオンラインのヘルプ フォーラムで見つけたいくつかのコマンドを実行して、できるだけ多くの情報を収集しようとしました。
sudo lshw -c ディスク
*-disk
description: SCSI Disk
product: JMS579
vendor: JMICRON
physical id: 0.0.0
bus info: scsi@4:0.0.0
logical name: /dev/sdb
configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512
sudo lshw -クラス ディスク -クラス ストレージ
*-usb:1
description: Mass storage device
product: USB Mass Storage
vendor: JMicron
physical id: 4
bus info: usb@2:4
logical name: scsi4
version: 1.00
serial: 152D00579000
capabilities: usb-2.10 scsi emulated scsi-host
configuration: driver=usb-storage maxpower=34mA speed=480Mbit/s
*-disk
description: SCSI Disk
product: JMS579
vendor: JMICRON
physical id: 0.0.0
bus info: scsi@4:0.0.0
logical name: /dev/sdb
configuration: ansiversion=6 logicalsectorsize=512 sectorsize=512
sudo hdparm -I /dev/sdb
/dev/sdb:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 0 MBytes
device size with M = 1000*1000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
sudo smartctl -a -d scsi /dev/sdb
=== START OF INFORMATION SECTION ===
Vendor: JMICRON
Product: JMS579
Compliance: SPC-4
Device type: disk
Local Time is: Fri Jun 22 23:07:23 2018 IST
device Test Unit Ready [unsupported scsi opcode]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
fdisk -l
このディスクはどこにもマウントされていないため、Fdisk では結果が表示されません。
sudo dmesg
[141307.332889] usb 2-4: USB disconnect, device number 5
[141310.499914] usb 2-4: new high-speed USB device number 7 using xhci_hcd
[141310.628540] usb 2-4: New USB device found, idVendor=152d, idProduct=0579
[141310.628544] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[141310.628547] usb 2-4: Product: USB Mass Storage
[141310.628549] usb 2-4: Manufacturer: JMicron
[141310.628551] usb 2-4: SerialNumber: 152D00579000
[141310.629107] usb-storage 2-4:1.0: USB Mass Storage device detected
[141310.629201] scsi host4: usb-storage 2-4:1.0
[141311.628514] scsi 4:0:0:0: Direct-Access JMICRON JMS579 PQ: 0 ANSI: 6
[141311.629170] sd 4:0:0:0: Attached scsi generic sg2 type 0
[141311.629942] sd 4:0:0:0: [sdb] Unit Not Ready
[141311.629953] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current]
[141311.629960] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.632053] sd 4:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[141311.632064] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current]
[141311.632072] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.632253] sd 4:0:0:0: [sdb] Write Protect is off
[141311.632261] sd 4:0:0:0: [sdb] Mode Sense: 00 00 00 00
[141311.632435] sd 4:0:0:0: [sdb] Asking for cache data failed
[141311.632441] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[141311.635917] sd 4:0:0:0: [sdb] Unit Not Ready
[141311.635927] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current]
[141311.635935] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.639186] sd 4:0:0:0: [sdb] Read Capacity(10) failed: Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[141311.639197] sd 4:0:0:0: [sdb] Sense Key : Illegal Request [current]
[141311.639205] sd 4:0:0:0: [sdb] Add. Sense: Invalid command operation code
[141311.639534] sd 4:0:0:0: [sdb] Attached SCSI disk
[141594.937486] EXT4-fs (sdb): unable to read superblock
[141594.937770] EXT4-fs (sdb): unable to read superblock
[141594.938048] EXT4-fs (sdb): unable to read superblock
[141594.938335] SQUASHFS error: squashfs_read_data failed to read block 0x0
[141594.938337] squashfs: SQUASHFS error: unable to read squashfs_super_block
/proc/partitions に sdb のレコードがありません
以下は私が試したさまざまな gdisk コマンドの出力です。
sudo gdisk
GPT fdisk (gdisk) version 1.0.1
Type device filename, or press <Enter> to exit: /dev/sdb
Problem reading disk in BasicMBRData::ReadMBRData()!
Warning! Read error 22; strange behavior now likely!
Warning! Read error 22; strange behavior now likely!
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
Command (? for help): i
no partitions
Command (? for help): o
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): Y
Command (? for help): p
Disk /dev/sdb: 0 sectors, 0 bytes
Logical sector size: 512 bytes
Disk identifier (GUID): ACBB4EFC-7AE9-4C9B-B804-DA09D936163D
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 18446744073709551582
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
Command (? for help): v
Problem: Disk is too small to hold all the data!
(Disk size is 0 sectors, needs to be 0 sectors.)
The 'e' option on the experts' menu may fix this problem.
Problem: GPT claims the disk is larger than it is! (Claimed last usable
sector is 18446744073709551582, but backup header is at
18446744073709551615 and disk size is 0 sectors.
The 'e' option on the experts' menu will probably fix this problem
Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.
Identified 3 problems!
Command (? for help): x
Expert command (? for help): e
Relocating backup data structures to the end of the disk
Expert command (? for help): z
About to wipe out GPT on /dev/sdb. Proceed? (Y/N): Y
Warning! GPT main header not overwritten! Error is 28
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
Expert command (? for help): p
Disk /dev/sdb: 0 sectors, 0 bytes
Logical sector size: 512 bytes
Disk identifier (GUID): 4B3EC7B7-2E9E-4933-885C-0CF09BFBE24C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 18446744073709551582
Partitions will be aligned on 2048-sector boundaries
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
Expert command (? for help): w
Caution! Secondary header was placed beyond the disk's limits! Moving the
header, but other problems may occur!
Warning! The claimed last usable sector is incorrect! Do you want to correct
this problem? (Y/N): Y
Have adjusted the second header and last usable sector value.
Partition(s) in the protective MBR are too big for the disk! Creating a
fresh protective or hybrid MBR is recommended.
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdb.
Unable to save backup partition table! Perhaps the 'e' option on the experts'
menu will resolve this problem.
Warning! An error was reported when writing the partition table! This error
MIGHT be harmless, or the disk might be damaged! Checking it is advisable.
Windows システムを使用して修正することも試みました。ディスク管理では不明、初期化されていないと表示されます。Diskpart も試しましたが、その下のさまざまなコマンドの出力は次のとおりです。
clean:
DiskPart succeeded in cleaning the disk
recover:
Virtual Disk Service error:
The disk is not initialized
convert gpt:
Virtual Disk Service error:
The system's information about the object may not be up to date
DiskPart has referenced an object which is not up-to-date.
Refresh the object by using the RESCAN command.
If the problem persists exit DiskPart, then restart DiskPart or restart the computer.
rescan:
Please wait while DiskPart scans your configuration...
Diskpart has finished scanning your configuration.
convert mbr: this one didn't work as well.
EaseUsも試しましたが、ドライブを検出できませんでした。
どのような助けでも大歓迎です、よろしくお願いします。
答え1
Diskpart は、明示的に強制しない限り、実際のデータには影響しません。データがまだ存在しているという仮定は正しいです。
SMART 診断 (たとえば、Ubuntu の Gnome-Disks 経由でアクセス可能) では、最終的なハードウェア障害が表示されますが、Windows がドライブにデータをアクティブに書き込んでいたようです。これは、リソースが空いているか、I/O 負荷が低いときに実行される遅延操作であるため、Windows 7 以降で非常に頻繁に発生します。
また、インデックス サービスは、収集したメタデータを保存するために、読み取り/書き込みモードで定期的に繰り返しドライブにアクセスします。今後これを防止し、即時書き込み/同期を強制したい場合は、次回 Windows 経由でドライブにアクセスするときに、ドライブのハードウェア プロパティでディスク キャッシュを有効にできます。ただし、ドライブをすばやく取り外す機能は使用できなくなるため、Linux ディストリビューションのマウント操作と同様に、SysTray のデバイス セレクターを使用してアンマウントする必要があります。
Windows ベースのソフトウェアまたは明示的に GUI アプリケーションを使用する場合は、Macrium Reflect が最適です。これは、アプリケーションとして Windows 内にインストールするか、その機能を使用して Windows PE ベースの Rescue システムを作成し、USB ドライブから Linux ライブ システムと同様に実行できます。
ただし、以下を使用することをお勧めします:
... これは、データ/パーティションの回復に最も信頼できるツールです。特に、ユーザーが変更を決定するまで、検出された可能性のあるパーティション構造に基づいてドライブの内容を変更しないからです。GUI はありませんが、ターミナル ウィンドウで実行され、ドライブ上の生のデータを実際にスキャンすることで、ファイル/フォルダー/パーティションをスキャンするための支援アプローチを提供します。
パーティション構造、それぞれの推定サイズと位置、パーティション ラベルの名前を覚えていれば、準備は完了です。正しいパーティションを識別するために必要なのはこれだけです。準備/スキャン/分析には、パーティション構造の復元/再作成よりも実際に時間がかかります。
TestDisk のテキスト インターフェイスに表示されるマニュアルと画面上の指示を読めば、ハードウェア障害でない場合はドライブが修復されます。
答え2
diskpart を使用してディスクをクリーンアップし、すべてのデータを破壊しました。これはよくありません。運が良ければ、メタデータのみが破壊され、ファイルはまだ残っています。運が良ければ、適切な製品でアクセスできるバックアップ メタデータがディスク上にある可能性もあります。
しかし、常に次のルール 1 を覚えておいてください。救出しようとしているディスクを決して変更しないでください。
バックアップがない場合、唯一の希望は回復製品を使用することです。
レビュー付きのそのような製品のリストについては、この記事をご覧ください。
最高の無料データ復旧およびファイル削除解除ユーティリティ。
すべての製品が同じアルゴリズムを使用しているわけではないので、1 つずつ試してください。一部のファイルを復旧できた場合は、復旧しようとしているディスクではなく、別のディスクに書き込みます。
同様のケースで最も効果的だと私が感じたのは、 MiniTool パワーデータリカバリただし、一度に 1 GB を超えるデータを回復するには、商用バージョン (69 ドル) が必要です。
ファイルが回復不可能であることが判明したが、あなたにとって非常に価値がある場合は、商業的な回収会社に連絡してください。ディスクを発送する必要がありますが、これらのサービスは高額であることに注意してください。したがって、選択する前にインターネットで調べて、サービスの評判をよく確認することをお勧めします。
インターネットで「データ救出」または「データ回復」を検索すると、市販の製品も見つかります。ディスクの分析は無料ですが、ファイルの回復には料金がかかる可能性がある無料ダウンロードのものもあります。
答え3
これはソフトウェアでは解決できない問題の兆候です。ソフトウェアをいじるのはやめてください。状況が悪化するだけかもしれません。
経験則として、(物理)ドライブが自分自身を正しく識別しなくなった瞬間適切な容量で、ソフトウェアだけでは解決/対処できない問題に対処していることになります。根本的な問題がメディアの損傷である場合、ソフトウェアを実行すると、潜在的にさらなる損傷を引き起こすだけです。ドライブが正しい容量で ID を停止した場合、この情報は主にプラッター (ファームウェア) に保存されており、メディアの損傷により破損している可能性があるため、PCB が原因である可能性は非常に低いです。
経験則として、ドライブが回転する場合、問題は PCB ではありません。
データが重要な場合は、この時点での最善のアドバイスは、データ復旧の専門家に依頼することです。多くのラボでは、無料で診断を行っています。データ復旧サービスには、定義上、数千ドルの料金がかかるという「常識」は、大規模なフランチャイズを避けない限り、神話です。多くのメディア タイプの問題、または「弱い」ヘッド、ファームウェアの問題は、クリーンルームでドライブを開けなくても処理できます。復旧に費用がかかるのは、多くの場合、クリーンルームでの作業が原因です。
ドライブを USB エンクロージャから取り外すことができる場合もありました。これにはいくつかの利点がありました。
- 筐体自体に問題がある可能性は排除できます。
- 軽微な読み取りの問題 (メディア/ヘッドの損傷) が発生した場合、エラー処理は、追加の USB レイヤーを処理するのではなく、ドライブのネイティブ インターフェイスに任せるのが最適です。ほとんどの USB ブリッジはエラー処理が下手です。たとえば、データのコピー中に常にハングする USB ドライブは、ネイティブ SATA ポートに接続すれば処理できる場合があります。
最近では、それほど単純ではなくなることがよくあります。
- USB エンクロージャは暗号化を提供/処理する場合があります。
- USB エンクロージャはドライブを 4K デバイスとして表示する場合があり、そのため 4K セクターを想定してパーティション分割、フォーマットなどが行われます。
- USB がドライブの PCB に統合されている場合、USB を簡単にバイパスすることはできない可能性があります。