友人がこれを持ってきました WD My Passport外付けハードドライブ 彼女のファイルを回復できるかどうかを確認するために私に持ってきました。停電後、デバイスは「機能していません」。彼女の証言によると、デバイスが接続されている場合、Windowsはドライブを「認識」しますが(それが意味するものは何でも)、彼女は「ファイルを見ることができません」。
私のUbuntu14.10マシンでは、次のようになります。
$ lsusb
Bus 004 Device 002: ID 1058:0748 Western Digital Technologies, Inc. My Passport 1TB USB 3.0
これらの2つのデバイスは、ドライブの接続中に表示されましたが、ドライブを取り外すと消えました。
crw-rw---- 1 root disk 21, 3 Jan 11 19:30 sg3
crw------- 1 root root 21, 4 Jan 11 19:30 sg4
/dev/
またはサブディレクトリの1つで何か他のものを見逃した可能性があります。次のファイルは、ドライブを取り外した後も残っているため、関連しているかどうかはわかりません。
$ ls -la /dev/usb
crw------- 1 root root 180, 0 Jan 11 19:00 hiddev0
ドライブへのSATAまたはIDEインターフェイス)を取得することを期待してケーシングを分解しましたが、デバイスのPCB上にUSB 3.0接続があります。空のジャンパーがいくつかあるように見えます(古いIDEドライブ)にあるものですが、ケーシングの外側からはアクセスできません。
このドライブをマウントするための次のステップは何ですか?理想的には、その内容を安全な場所にdd
したいと思います。 fsck
少しの祈りを込めて。 Western Digitalはどちらのパーティションタイプのデバイスも販売しているようであるため、デバイスがFATまたはNTFSのどちらでフォーマットされているかはわかりません。 /dev/sg3
または/dev/sg4
を間違ったタイプのFATまたはNTFSとしてマウントしようとすると、追加の損傷を与える可能性がありますか?
編集:/dev/sg3
および/dev/sg4
のデバイスはマウントされません。マウント試行の結果は次のとおりです。
$ ls -la | grep sg
drwxr-xr-x 2 root root 140 Jan 11 20:43 bsg
crw-r--r-- 1 root root 1, 11 Jan 11 19:00 kmsg
crw-rw---- 1 root disk 21, 0 Jan 11 19:00 sg0
crw-rw----+ 1 root cdrom 21, 1 Jan 11 19:00 sg1
crw-rw---- 1 root disk 21, 2 Jan 11 19:00 sg2
crw-rw---- 1 root disk 21, 3 Jan 11 20:43 sg3
crw------- 1 root root 21, 4 Jan 11 20:43 sg4
$ mkdir ~/inbal
$ Sudo mount -t ntfs /dev/sg
sg0 sg1 sg2 sg3 sg4
$ Sudo mount -t ntfs /dev/sg4 ~/inbal
[Sudo] password for dotancohen:
Error reading bootsector: Illegal seek
Failed to sync device /dev/sg4: Invalid argument
Failed to mount '/dev/sg4': Illegal seek
$ Sudo mount -t ntfs /dev/sg3 ~/inbal
Error reading bootsector: Illegal seek
Failed to sync device /dev/sg3: Invalid argument
Failed to mount '/dev/sg3': Illegal seek
$ Sudo mount -t vfat /dev/sg4 ~/inbal
mount: /dev/sg4 is not a block device
$ Sudo mount -t vfat /dev/sg3 ~/inbal
mount: /dev/sg3 is not a block device
私はこれが古い質問であることを知っています、そしてこの答えは実際には私が十分な評判を持っていないコメントであるべきです、しかし私はここである種の警告を与えるべきだと思います:
読み取り専用をマウントしようとしても、ドライブへの書き込みアクセスが発生する可能性があります!
最良の例は、Reiserfsパーティションを読み取り専用(!)でマウントすることです。これにより、マウントの前後に取得したパーティションイメージを比較することで簡単に確認できるように、ディスクの少なくとも1バイトが変更されます。 Reiserfsバージョン3.6.24で再び見られます。そこで増加しているのは、ある種のマウントカウンターだと思います。
古いNTFSドライバでも同様のことがわかりましたが、パーティションを再度アンマウントした後、ディスク上の変更が元に戻されました。注意:読み取り専用マウントについて話しています!
したがって、ディスクをレスキューしようとすると、読み取り専用のものであっても、マウントが試行される前にdd
(または同様のもの)が実行されます。
質問で説明されている場合のもう1つの障害は、カーネルがドライブにアクセスするためのブロックデバイスを確立できなかったという事実です。
/dev
のls
リストからわかるように、sg*
ファイルは文字デバイスです。これらは、SCSIコマンドを使用して下位レベルのデバイスと通信するために使用されます。たとえば、 SCSI-Generic-HOWTO を参照してください。このようなデバイスは、マウントコマンドでは使用できません。
/proc/partitions
に表示されるそのドライブのブロックデバイスがない場合、Smartmontools、hdparm
、testdisk
、さらにはdd
などの診断およびレスキューツールの大部分は除外する。
そのためには本当に良いウィザードが必要だと思います。