16GB の Lexar フラッシュ ドライブからファイルを復元する必要があります。PCB は損傷していないように見えるので、復元できると期待しています。USB を Windows マシンに接続すると、ドライブとして認識されますが、ディスクを挿入するように求められます。このデバイスを動作させるのに数日間試行した後、Ubuntu で試してみることにしました。
次のコマンドを実行しますlsusb:
Bus 002 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 8086:0186 Intel Corp. WiMAX Connection 2400m
Bus 001 Device 003: ID 0bda:5801 Realtek Semiconductor Corp.
Bus 001 Device 007: ID 058f:1234 Alcor Micro Corp. Flash Drive
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
フラッシュドライブは Alcor Micro Corp. として認識されています。ここまでは順調です。ただし、以下を実行するとsudo fdisk -l:
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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: 0xb43778ae
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 3074047 1536000 27 Hidden NTFS WinRE
/dev/sda2 3074048 921657343 459291648 7 HPFS/NTFS/exFAT
/dev/sda3 954587136 976773119 11092992 17 Hidden HPFS/NTFS
/dev/sda4 921659390 954587135 16463873 5 Extended
/dev/sda5 921659392 954587135 16463872 83 Linux
Partition table entries are not in disk order
ドライブが認識されません。最終的に、以下を実行しましたtail -f:
==> /var/log/syslog <==
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.398762] usb 1-1.2: new high-speed USB device number 9 using ehci-pci
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644599] usb 1-1.2: New USB device found, idVendor=058f, idProduct=1234
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644610] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644616] usb 1-1.2: Product: Mass Storage Device
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.644621] usb 1-1.2: Manufacturer: Alcor Micro
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.645100] usb-storage 1-1.2:1.0: USB Mass Storage device detected
Mar 24 08:55:10 danny-Satellite-E305 kernel: [ 6791.645183] scsi13 : usb-storage 1-1.2:1.0
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.642812] scsi 13:0:0:0: Direct-Access Generic USB Flash Disk 7.76 PQ: 0 ANSI: 4
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.643071] sd 13:0:0:0: Attached scsi generic sg2 type 0
Mar 24 08:55:11 danny-Satellite-E305 kernel: [ 6792.647022] sd 13:0:0:0: [sdb] Attached SCSI removable disk
データを回復するためのアイデアはありますか? よろしくお願いします!
答え1
問題のあるデバイスのイメージを作成しますddrescue- ドライブに保存されている (または保存されていた) データの量に関係なく、ドライブ全体を保存できる十分なストレージ スペースが必要になります。この場合、/dev/sdb のクローンを保存するには 16 GB が必要になるようです。
ddrescue は作業を実行するプログラムであり、インストールされていない場合はインストールする必要がありますsudo apt-get install gddrescue(タイプミスではありません。g は GNU の略です)
ターミナルを開きCtrlAltT、画像ファイルを保存するディレクトリに移動して、次のコマンドを実行します。sudo ddrescue -d /dev/sdb sdb.img sdb.logfile
-d はドライブへの直接アクセスを指示します (キャッシュを無視) /dev/sdb は入力に使用するデバイスです sdb.img は出力に使用するファイルです sdb.logfile は現在の場所と結果を追跡します。
何らかの理由でプロセスが完了前に停止した場合でも、ログファイルにより中断したところから再開できます。
イメージングが開始され、次のような画面が表示されます。
Rescued は正常に読み取られたデータの量を示し、errsize は読み取り不能なデータのサイズを示します。プロセスが継続するにつれて、前者が増加し、後者がゼロに近づくことを期待します。ddrescue は、失敗したブロックを半分にして再試行するデータ カービングと呼ばれるプロセスを使用します。
ddrescueは非常に強力なツールであり、これについて多くのことを学ぶことができます。マニュアル。 第3章も注目です!!出力に間違ったファイルやデバイスを選択すると、間違いなく一日が台無しになります。
結果イメージを取得したら、障害が発生したデバイスや故障したデバイスにさらなる負担をかけずに、テストと回復手順を実行できます。
最終的に、ddrescue はターミナル画面に「Finished」を出力します。errsize が大きく、もう少し回復を試みる必要がある場合は、コマンドを再実行し、失敗したブロックを再試行するスイッチを適用して、逆方向に読み取ることもできます (ソリッド ステート デバイスでは役に立たない可能性があります)。または、sudo ddrescue -d --try-again --retrim --reverse /dev/sdb sdb.img sdb.logfile前述のマニュアルで役立つと思われるその他のスイッチの組み合わせを適用します。すべてのデータの回復を試行し終えたら、何が得られたかを確認します。
コマンドfdisk -l sdb.imgまたはイメージに付けた名前を発行します。運が良ければ、パーティション テーブルがそのままであることを示す次のような出力が表示されます。
Disk sdb.img: 4013 MB, 4013948928 bytes
1 heads, 24 sectors/track, 326656 cylinders, total 7839744 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: 0x000174fe
Device Boot Start End Blocks Id System
sdb.img1 * 2048 7839743 3918848 b W95 FAT32
「開始」番号に注意してください。これは、ファイル システムがセクター 2048 から始まることを意味します。
この情報と基本的な数学スキルまたは計算機があれば、プロセスを試すのに必要なオフセットを見つけることができます。2048 セクター × 512 バイト / = 1048576
このイメージは失敗により作成されたため、まずファイルシステムの修復を試みます。
sudo losetup --offset 1048576 /dev/loop2 sdb.imgループ デバイスにイメージを設定するコマンドを発行します。
次にコマンドを発行するsudo fsck /dev/loop2
システムを可能な限り修復した後、マウントポイントを作成しsudo mkdir /mnt/loop、以前にセットアップしたループデバイスをマウントします。sudo mount /dev/loop2 /mnt/loop
これで、別のドライブにコピーできるデータができたと思います。見てみましょう:
ls /mnt/loop
autorun.inf casper-rw ldlinux.sys pool smart-fail.txt
boot dists md5sum.txt preseed syslinux
casper install pics README.diskdefines wubi.exe
いくつかあるようです。皆さんもそうであることを願っています。ファイルのコピーが終わったら、ループデバイスをアンマウントします。sudo umount /dev/loop2
この方法がうまくいかなかった場合は、`sudo testdisk sdb.img (またはイメージ ファイルに付けた名前) コマンドを使用して testdisk を試すこともできます。Enter キーを押してイメージを選択し、パーティション タイプを選択します。タイプが検出された場合は、続行方法についてのヒントが表示されます。これは通常、フラッシュ ドライブ上の Intel であることに注意してください。
失われたパーティションを検索するには、[分析] を選択するか、ファイル システム ツールの [詳細設定] に直接進み、既知のパーティションまたは回復されたパーティションを選択できます。パーティションを選択すると、コピーするファイルの選択方法などに関する指示を含むファイル リストが表示されます。この部分は非常にわかりやすく、おそらく他の場所で説明されているので、ここで説明を終了します。不明な点がある場合は、コメントを残していただければ、折り返しご連絡いたします。