故障した1TBドライブからデータを回復しています（ハードドライブを交換する手順は何ですか？）。システム回復USBでこれを行ったddrescue結果、エラーサイズは557568Bで、191個のエラーがあることがわかりました。おそらくすべてエラー/homeです。 （いわゆる「エラー」は、不良セクタではなく一連の不良セクタであると仮定します。）。
今私が見たいくつかのガイドでは、e2fsck新しいディスクでこれを行うことを提案しました。一部のファイルが「空のセクタ/ブロック」に割り当てられていることを発見して、少なくともどのファイルがそのファイルをすべて保持していないかを知ることができます。 。しかし、まったくエラーが見つかりませんでした（-y何も見逃していないことを確認せずに実行しました）。今まで95％のエラーが見つからない状態で再実行しています-c。いつか、そのファイルが使用されるまで、ゼロ以外のランダムなフラグメントを持つ正常に見えるファイルがあるようです。ソフトウェアがファイルを開くと検出されます。 、またはLinux Mintが要求するとき。
潜在的に破損したファイルのリストを取得するために既存/新しいドライブに実行できることはありますか？ 191個がファイルにまたがる可能性があるため、その数がどれくらいになるのかわかりませんが、少なくとも私が最も心配するのは古い家族の写真とビデオ（それぞれ1MB以上）です。 、残りは関係がないか、最近バックアップされている可能性があります。
アップデート：e2fsckの新しいチャンネルは、私がまったく知らなかったいくつかの新機能を提供します。
Block bitmap differences: +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes
ベストアンサー1
見つかったすべての不良ブロックのブロック番号が必要です（ddrescueリストを提供し、保存してください）、次にこれらのブロックを使用するファイルを見つけます（例：ここ）。不良ブロックが多い場合は、このスクリプトを作成する必要があります。
e2fsck役に立ちません。ファイルシステム自体の一貫性のみを確認するため、「管理」ファイルシステム情報を含む無効なブロックでのみ機能します。
ファイルの不良ブロックは空です。
編集する
さて、ブロックサイズを見てみましょう。 512バイトのデバイスブロックを使用して試用版ファイルシステムを作成しましょう。
$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs
$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs
$ /sbin/tune2fs -l fs
...
Block count: 100
...
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
したがって、ファイルシステムブロックサイズは1024で、100個のファイルシステムブロック（および200個の512バイトデバイスブロック）があります。救う:
$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued: 102400 B, errsize: 0 B, current rate: 102 kB/s
ipos: 65536 B, errors: 0, average rate: 102 kB/s
opos: 65536 B, run time: 1 s, successful read: 0 s ago
Finished
$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time: 2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos current_status
0x00010000 +
# pos size status
0x00000000 0x00019000 +
$ printf "%i\n" 0x00019000
102400
したがって、16進ddrescue単位はブロックではなくバイトです。最後に、何が役に立つかを見てみましょうdebugfs。まず、ファイルを作成してその内容を探します。
$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp
$ hexdump -C fs
...
00005400 61 62 63 64 65 66 67 68 69 6a 6b 0a 00 00 00 00 |abcdefghijk.....|
00005410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
したがって、データのバイトアドレスは0x5400。これを1024バイトのファイルシステムブロックに変換します。
$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21
ブロック範囲も試してみましょう。
$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs: testb 0
testb: Invalid block number 0
debugfs: testb 1
Block 1 marked in use
debugfs: testb 99
Block 99 not in use
debugfs: testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs: testb 21
Block 21 marked in use
debugfs: icheck 21
Block Inode number
21 12
debugfs: ncheck 12
Inode Pathname
12 //foo
したがって、結果は期待どおりですが、ブロック0は無効です。それはおそらくファイルシステムのメタデータがあるからです。したがって0x30F8A71000、そのバイトアドレスに対してddrescueパーティションではなくディスク全体で作業していると仮定すると、パーティションが起動するバイトアドレスを減算します。
210330128384 - 7815168*512 = 206328762368
これをtune2fsブロックサイズに分割してファイルシステムブロックを取得します。 （破損した複数の物理ブロックがファイルシステムブロックを構成するため、数値が正確な倍数である必要はありません。）
206328762368/4096=50373233.0
これがテストする必要があるブロックですdebugfs。