3TBのUSB HDDを持っていますが、Ubuntuでは次のように報告されます
Jul 15 13:30:00 ris kernel: [11395.274460] usb 1-1.3: New USB device found, idVendor=152d, idProduct=2329
Jul 15 13:30:00 ris kernel: [11395.274474] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
Jul 15 13:30:00 ris kernel: [11395.274477] usb 1-1.3: Product: USB to ATA/ATAPI bridge
Jul 15 13:30:00 ris kernel: [11395.274479] usb 1-1.3: Manufacturer: JMicron
Jul 15 13:30:00 ris kernel: [11395.274481] usb 1-1.3: SerialNumber: 71F14D08
Jul 15 13:30:00 ris kernel: [11395.275147] usb-storage 1-1.3:1.0: USB Mass Storage device detected
Jul 15 13:30:00 ris kernel: [11395.275324] usb-storage 1-1.3:1.0: Quirks match for vid 152d pid 2329: 8020
Jul 15 13:30:00 ris kernel: [11395.275401] scsi9 : usb-storage 1-1.3:1.0
Jul 15 13:30:00 ris mtp-probe: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3"
Jul 15 13:30:00 ris mtp-probe: bus: 1, device: 6 was not an MTP device
Jul 15 13:30:01 ris kernel: [11396.306993] scsi 9:0:0:0: Direct-Access ST3000DM 001-9YN166 CC9F PQ: 0 ANSI: 5
Jul 15 13:30:01 ris kernel: [11396.307439] sd 9:0:0:0: Attached scsi generic sg3 type 0
Jul 15 13:30:01 ris kernel: [11396.308206] sd 9:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
Jul 15 13:30:01 ris kernel: [11396.308685] sd 9:0:0:0: [sdc] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
Jul 15 13:30:01 ris kernel: [11396.309648] sd 9:0:0:0: [sdc] Write Protect is off
Jul 15 13:30:01 ris kernel: [11396.309654] sd 9:0:0:0: [sdc] Mode Sense: 28 00 00 00
Jul 15 13:30:01 ris kernel: [11396.312843] sd 9:0:0:0: [sdc] No Caching mode page found
Jul 15 13:30:01 ris kernel: [11396.312849] sd 9:0:0:0: [sdc] Assuming drive cache: write through
Jul 15 13:30:01 ris kernel: [11396.313668] sd 9:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
Jul 15 13:30:01 ris kernel: [11396.339275] sdc: sdc1 sdc2
Jul 15 13:30:01 ris kernel: [11396.340615] sd 9:0:0:0: [sdc] Very big device. Trying to use READ CAPACITY(16).
Jul 15 13:30:01 ris kernel: [11396.378241] sd 9:0:0:0: [sdc] Attached SCSI disk
lsusb は
Bus 001 Device 006: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp. JM20329 SATA Bridge
fdisk -l
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes
255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052cdb
Device Boot Start End Blocks Id System
/dev/sdc1 196626432 732566271 267969920 7 HPFS/NTFS/exFAT
/dev/sdc2 256 196626431 98313088 83 Linux
gparted では未割り当てと表示され、Windows では未割り当てと表示されます。この HDD を回復する方法はありますか?
答え1
これは、あなたの状況で私が個人的に行うであろうことについての説明です。これから述べることは、保証を無効にします。まず、保証がある場合はそれを調べてください。保証がない場合は、これを検討してください。
USB エンクロージャからハードドライブを取り外します。デバイスはおそらく SATA だと思います。次に、SATA ハードドライブをデスクトップ PC の 1 つにインストールします。その時点で、より深刻なハードウェア障害が発生しない限り、Linux を起動し、ディスク ユーティリティ (gnome-disks) を使用してディスクの SMART データを確認します。ここまで進んだら、SMART データを投稿してください。
ディスクに IO エラーやセクター障害などがあっても、まだ動作する場合は、別の 3TB 以上のディスクを入手し、そのメディアにクローンを作成します。
ディスクが原因で起動に問題が発生したり、システムが不安定になったり、ディスクが認識されなかったり、回転しなかったり、その他の問題が発生したりする場合は、専門的なデータ復旧を検討します。
ディスクが認識され、マウントされているが、ファイルが見つからない場合、その詳細を投稿します。
すべて揃っていて、ディスクが動作していて、SMART データに問題がなく、ファイルを復元できれば、USB インターフェイスが問題の原因であることがわかります。これで作業は完了です。
そうでなければ結果を報告してください。そうすれば私の回答を修正します。
繰り返しますが、私がお勧めするのは、ご自身のリスクと責任において、まずハードドライブを USB エンクロージャから取り外し、ハードウェアの状態を評価することです。
答え2
何か他のことをする前に、ドライブのイメージを作成し、読み取り専用としてマークして、それを使ってみることを強くお勧めします。物理ドライブを接続した状態で必要以上に時間を費やすと、何か問題が発生する可能性が高くなります。つまり、物理的な欠陥が悪化するか、誤って愚かなことをしてしまうかのどちらかです。
クラシック
dd if=/dev/sdc of=/somewhere/with/3TB/of/free/space.img
ドライブに物理的な問題がない場合には使用できますが、物理的な問題がある場合は中止され、部分的なイメージで最初からやり直すことになります。
より優れた dd のようなバリアントがあり、エラーをより適切に処理します。少なくとも、エラーをスキップして、ブロックをゼロにする必要があります。優れたものは再試行します。賢いものは、その場で再試行するのではなく、エラーを記憶して、ディスクの残りの部分を取得した後に再試行します。優れたツールは、エラーが 1 つ以上連続して発生した場合、ディスクの同じセクションを連続して読み取り続けるのではなく、エラーのない読み取りが再び得られるまで、1 回目のパスで徐々に大きなセクションをスキップします。スパース イメージ ファイルを作成できるため、必ずしも 3TB の空き領域が必要ないのも便利です。
「safecopy」は、エラーを無視して完全なイメージを取得できる dd のようなプログラムの 1 つです。私の最後の物理リカバリ作業では、最終的に GNU DDRescue に落ち着きました。使用方法は次のとおりです。
ddrescue -r 3 /dev/sdc /somewhere/with/3TB/of/free/space.img /somewhere/else/recovery_work.log
データの別のコピー (ディスク イメージ ファイル) ができたら、安心して実際にファイルの取得を開始できます。他の誰かが述べたように、photorec は、ディレクトリ エントリがなくても (パーティション データがない raw ディスク検索を含む)、削除されたファイルを見つけるのに優れたプログラムです。このプログラムは、ディスク セクターで「マジック ナンバー」、つまり特定のファイル タイプに固有の先頭 (場合によってはさらに先) のバイト パターンを検索することによって機能します。
答え3
雷が外付け 3TB WD HDD を破壊したので、ケースから取り出しました。ケース内の電源は壊れていましたが、HDD はなんとか動作しました。ドライブをコンピューターにインストールすると、何年も使っていなかった非常に古いパーティション テーブルが表示されました。
データを回復するために、ddrescue を実行しました (実行に 7 時間以上かかりました)。重要なファイルのいくつかは回復できましたが、ドライブに保存されていたファイルの大部分は失われました。
ドライブ自体は今のところ問題なく動作しています。
私が抱えていた最大の問題は、HDD 上でパーティションを何度も作成したり削除したりしたことでした。各パーティション テーブルと、その中のすべてのファイルのリストはまだそこにありました。ドライブからデータを再び回復したいのであれば、パーティションを変更する前にディスク ワイプを実行する必要があるという結論に達しました。
ドライブをキャビネットから取り出す前に、必要なデータがドライブよりも価値があるかどうかを判断する必要がありました。購入後 3 か月で 3 年間の保証を破棄し、さらに 5 年間の延長保証も購入しました。残念ですが、これも選択肢の 1 つです。
答え4
HDD の不良セクタを見つけるために badblocks を試し、その後これらのセクタを無視することができます。詳細については、こちらを参照してください。
http://linuxpoison.blogspot.in/2008/01/howto-check-disk-drive-for-errors-and.html
回復ソフトウェアを使用します。