ddrescue リカバリの試行によって失われたファイルを見つけるにはどうすればよいですか?

Question 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 個あります (および 512 バイトのデバイスブロックが 200 個あります)。これを修復します。

$ 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。

Answer

遭遇したすべての不良ブロックのブロック番号が必要になります（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 個あります (および 512 バイトのデバイスブロックが 200 個あります)。これを修復します。

$ 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。

Question 2

NTFS、ext3、ext4

故障したドライブからデータをコピーした後ddrescue、ddrutility影響を受けるファイル名を見つけます。

ddrescueマップファイルを指定して、20 秒以内に1TB パーティション上の影響を受ける NTFS ファイルを一覧表示することに成功しました。

ログファイルを現在のディレクトリに書き込みます。

リンク先のページには、NTFS、ext3、ext4 のサポートについて記載されています。

btrfs、zfs

これらのファイルシステムには独自の組み込みscrub関数があります。

Answer

NTFS、ext3、ext4

故障したドライブからデータをコピーした後ddrescue、ddrutility影響を受けるファイル名を見つけます。

ddrescueマップファイルを指定して、20 秒以内に1TB パーティション上の影響を受ける NTFS ファイルを一覧表示することに成功しました。

ログファイルを現在のディレクトリに書き込みます。

リンク先のページには、NTFS、ext3、ext4 のサポートについて記載されています。

btrfs、zfs

これらのファイルシステムには独自の組み込みscrub関数があります。

Question 3

すでに実装されているというユーティリティをお勧めしますddrutility。これにより、手作業による面倒な計算が不要になります。

クローン上で実行する必要がありますコピー(オリジナルではない) ドライブデバイスは次のようになります。

ddru_findbad /dev/sdb /ddrescue-disk-copy.map

ここではマップファイル (2 番目の引数) の使用が必須です。

このユーティリティは非常にスマートで、さまざまなファイルシステム (NTFS も含む) をサポートし、まだ分割されていないエラーのあるセクターをテストする機能 (一時的に不良としてマークする) も備えているため、手順全体をddrescue完了する必要があるかどうかを見積もることができます。また、ディスク全体が元々クローンされているため、/dev/sdbここではがディスク全体 ( のようなパーティションではない/dev/sdb1) として使用されていることに注意してください。

このユーティリティは Debian リポジトリで入手でき、次のコマンドでインストールできます。

sudo apt install ddrutility

プロジェクトのウィキ:https://sourceforge.net/p/ddrutility/wiki/ホーム

Answer

すでに実装されているというユーティリティをお勧めしますddrutility。これにより、手作業による面倒な計算が不要になります。

クローン上で実行する必要がありますコピー(オリジナルではない) ドライブデバイスは次のようになります。

ddru_findbad /dev/sdb /ddrescue-disk-copy.map

ここではマップファイル (2 番目の引数) の使用が必須です。

このユーティリティは非常にスマートで、さまざまなファイルシステム (NTFS も含む) をサポートし、まだ分割されていないエラーのあるセクターをテストする機能 (一時的に不良としてマークする) も備えているため、手順全体をddrescue完了する必要があるかどうかを見積もることができます。また、ディスク全体が元々クローンされているため、/dev/sdbここではがディスク全体 ( のようなパーティションではない/dev/sdb1) として使用されていることに注意してください。

このユーティリティは Debian リポジトリで入手でき、次のコマンドでインストールできます。

sudo apt install ddrutility

プロジェクトのウィキ:https://sourceforge.net/p/ddrutility/wiki/ホーム

Question 4

私は Filezilla をシンプルに使用して問題を解決しました。通常の Filezilla を使用して、すべての正常なデータをバックアップします。1 つの大きなファイルが正しくコピーされていないことに気付きました (途中で停止し、転送を再開します)。幸い、同じファイルの以前のバックアップがあります。ディスクを複製するには、次の手順を使用してディスク上の不良ブロックを見つける必要がありました。

まず、HD情報を使用して問題のあるディスクを見つけますfdisk -l

2番目に、ディスクが/dev/sdb次にコマンドを実行する必要があります 不良ブロック -v /dev/sdbドライブ上の不良ブロックがすべてリストされます。幸い、いくつかあります。不良ブロックが見つからない場合は、ドライブのブロックは正常であり、他の原因を見つける必要があります。私のブロックサイズは512なので、DDを実行するにはそのデフォルトの数値を使用します。

3番目に、各ブロックのサイズは512なので、bs=512に設定します。

いつものようにDDを定期的に実行するたびに、エラーが発生した後のデータが破損します。そこで、ページで説明されているパラメータを使用します。https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html「故障したディスクの場合」の部分を検索します。

dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock

しばらく時間がかかりました。不良ブロックに遭遇するたびに、故障したドライブを叩くような音がします。ブロックごとにコピーしますが、すべての不良ブロックで同じ音がします。音が鳴った回数は、別の不良ブロックが見つかり、ディスプレイにエラーメッセージが表示されるためです。'conv=エラーなし、同期'不正な読み取りをNULで埋めるのに対し、'iflag=フルブロック'短い読み取りに対応しますが、最後までデータを同期させます。破損はまったくなく、問題のあるブロックをコピーせず、空の NUL で埋めるだけです。

DD によるコピーが完了したら、過去のバックアップから Filezilla を戻して不良ファイルを置き換えたところ、すべて正常に動作しました。故障したドライブをバックアップしようとしている他の方にも、この情報が役立つことを願っています。

注: 私の不良ブロックは互いにかなり接近していました。一度に 4 ブロックほどがグループになって不良として検出されました。ブロックがディスク全体に散らばっている場合は、複数のファイルが影響を受ける可能性があります。幸い、私のケースでは、大きな 4 GB のデータベースファイルだけが影響を受けました。

Answer

私は Filezilla をシンプルに使用して問題を解決しました。通常の Filezilla を使用して、すべての正常なデータをバックアップします。1 つの大きなファイルが正しくコピーされていないことに気付きました (途中で停止し、転送を再開します)。幸い、同じファイルの以前のバックアップがあります。ディスクを複製するには、次の手順を使用してディスク上の不良ブロックを見つける必要がありました。

まず、HD情報を使用して問題のあるディスクを見つけますfdisk -l

2番目に、ディスクが/dev/sdb次にコマンドを実行する必要があります 不良ブロック -v /dev/sdbドライブ上の不良ブロックがすべてリストされます。幸い、いくつかあります。不良ブロックが見つからない場合は、ドライブのブロックは正常であり、他の原因を見つける必要があります。私のブロックサイズは512なので、DDを実行するにはそのデフォルトの数値を使用します。

3番目に、各ブロックのサイズは512なので、bs=512に設定します。

いつものようにDDを定期的に実行するたびに、エラーが発生した後のデータが破損します。そこで、ページで説明されているパラメータを使用します。https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html「故障したディスクの場合」の部分を検索します。

dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock

しばらく時間がかかりました。不良ブロックに遭遇するたびに、故障したドライブを叩くような音がします。ブロックごとにコピーしますが、すべての不良ブロックで同じ音がします。音が鳴った回数は、別の不良ブロックが見つかり、ディスプレイにエラーメッセージが表示されるためです。'conv=エラーなし、同期'不正な読み取りをNULで埋めるのに対し、'iflag=フルブロック'短い読み取りに対応しますが、最後までデータを同期させます。破損はまったくなく、問題のあるブロックをコピーせず、空の NUL で埋めるだけです。

DD によるコピーが完了したら、過去のバックアップから Filezilla を戻して不良ファイルを置き換えたところ、すべて正常に動作しました。故障したドライブをバックアップしようとしている他の方にも、この情報が役立つことを願っています。

注: 私の不良ブロックは互いにかなり接近していました。一度に 4 ブロックほどがグループになって不良として検出されました。ブロックがディスク全体に散らばっている場合は、複数のファイルが影響を受ける可能性があります。幸い、私のケースでは、大きな 4 GB のデータベースファイルだけが影響を受けました。

ddrescue リカバリの試行によって失われたファイルを見つけるにはどうすればよいですか?

答え1

答え2

NTFS、ext3、ext4

btrfs、zfs

答え3

答え4

関連情報