web-dev-qa-db-ja.com

どうすれば、ddrescueリカバリーの試行によって失われたファイルを見つけることができますか？

1 TB障害のあるドライブからデータをサルベージしている最中です（ ハードディスクの交換手順）で質問されました ）ddrescueシステムレスキューUSBの結果、エラーサイズ557568 B、191エラー、おそらくすべて/home（「エラー」と呼ばれるものは不良セクターではなく、連続したシーケンスであると思います）。

今、私が見たいくつかのガイドは、新しいディスクでe2fsckを実行することを提案しています。これにより、いくつかのファイルに「空白のセクター/ブロック」が割り当てられていることがわかり、少なくともファイル全体を保存できませんでした。しかし、エラーはまったく見つかりませんでした（私は何も見逃していないことを確認するために-yなしで実行しました）。現在、-cを使用して再度実行していますが、これまでのところ95％のエラーは見つかりませんでした。私は新しいドライブを持っていると思います。内部にゼロまたはランダムな断片が含まれている正常に見えるファイルがいくつかあり、対応するソフトウェアで開くか、Linux Mintで必要になるまで検出できません。

破損している可能性のあるファイルのリストを取得するために、古いドライブまたは新しいドライブで何かを実行できますか？ 191はファイルをまたぐことができるので、それらがいくつあるかはわかりませんが、少なくとも合計サイズは大きくありません。私は大きな家族の古い家族の写真とビデオ（それぞれ1 MB以上）について主に心配しています。残りはおそらく無関係であるか、最近バックアップされました。

更新：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
hard-diskdata-recoveryddrescue
7
David Sevilla

遭遇したすべての不良ブロックのブロック番号が必要です（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が無効であることを除いて、それは期待どおりに機能します。おそらくファイルシステムのメタデータがそこにあるためです。したがって、ddrescueからのバイトアドレス0x30F8A71000について、パーティションではなくディスク全体で作業したと想定して、パーティションのバイトアドレスを減算します。

210330128384-7815168 * 512 = 206328762368

これをtune2fsブロックサイズで割り、ファイルシステムブロックを取得します（物理的な、破損している可能性のある複数のブロックがファイルシステムブロックを構成するため、数値は正確な倍数である必要はありません）。

206328762368/4096 = 50373233.0

これがdebugfsでテストする必要のあるブロックです。

3
dirkt

NTFS、ext3、ext4

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

ddrescueマップファイルを20秒未満で指定すると、1TBパーティション上の影響を受けるNTFSファイルをリストすることに成功しました。

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

リンク先のページでは、NTFS、ext3、ext4のサポートについて言及しています。

btrfs、zfs

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

2
Tom Hale

最も簡単な方法は、必ずしも最速または最も効率的な方法とは限りませんが、次のようになります。

  1. Ddrescueを通常どおり実行してドライブ全体をレスキューし、必ずmapfileを保存してください。
  2. 塗りつぶしモードでddrescueを再実行して、不良セクターを一意のパターンでマークします。彼らはこのようなものを推奨します：
    ddrescue --fill-mode=- <(printf "BAD-SECTOR ") outfile mapfile
    誤検知を軽減するために、通常はどのファイルにも存在しないパターンを使用する必要があります。
  3. レスキューされたイメージ/ディスクをネイティブオペレーティングシステムでマウントします。
  4. Linuxのe2fsckなどの適切なオペレーティングシステムユーティリティを使用して、ファイルシステムのディレクトリ構造を確認し、場合によっては修復します。ファイルシステムの構造に該当する不良セクターは、すべてのファイルの破損を探す前に、まず解決する必要があります。

    ディレクトリ構造の修復は、この答えの範囲外である、それ自体の芸術です。

  5. grepなど、オペレーティングシステムが提供する適切なユーティリティを使用して、ファイルシステム上のすべてのファイルをスキャンし、フィルモードでマークされた一意のパターンを含むファイルをリストします。
  6. 必要に応じて、適切なエディターでファイルを調べて、ファイル内の固有のパターンを検索することにより、実際のデータ損失の位置を見つけることができます。

これはオペレーティングシステムに依存しないため、特定のファイルシステムタイプによって異なる詳細は意図的に示していません。私は最初にWindowsユーティリティを使用してNTFSファイルシステムでこれを行わなければなりませんでしたが、ext3/4などでも同じ考えです。

1
tlum