ddrescue
故障したSSDを私が書くことができると想像したりdd
(記憶が長すぎる)。結果 .img の場合、インストール可能と認識されないディスクを焼いた。
ディスクで使用した後、e2fsck -fyvC 0
それをマウントして元のSSDにあったファイルの一部(すべてではない)を復元できます。
これがデータ検索のための最良の選択ですか、それともより多くのデータを回復するためのより良いツールがありますか?
e2fsck
上記のフラグを使用して実行すると、孤立または削除されたinodeに関するさまざまな警告が表示されます。これは修正または削除されました。残念ながら、これらは私がディスクで最も探しているデータと一致しているようです。
出力は227,000行です。以下はいくつかの主要な内容です。
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? yes
*** journal has been deleted ***
Superblock has_journal flag is clear, but a journal is present.
Clear? yes
Truncating orphaned inode 6302578 (uid=1000, gid=1000, mode=0100664, size=3600)
Pass 1: Checking inodes, blocks, and sizes
[...]
Inode 1048618 was part of the orphaned inode list. FIXED.
Inode 1048634 was part of the orphaned inode list. FIXED.
Deleted inode 1048662 has zero dtime. Fix? yes
[...]
Entry '..' in <6291748>/<9965526> (9965526) has deleted/unused inode 6291748. Clear? yes
[...]
Unattached inode 9712327
Connect to /lost+found? yes
Inode 9712327 ref count is 2, should be 1. Fix? yes
[...]
Free blocks count wrong for group #740 (32768, counted=3012).
Fix? yes
[...]
Directories count wrong for group #4593 (0, counted=114).
Fix? yes
[...]
Padding at end of inode bitmap is not set. Fix? yes
Recreate journal? yes
Creating journal (262144 blocks): Done.
*** journal has been regenerated ***
/dev/sdc: ***** FILE SYSTEM WAS MODIFIED *****
2205797 inodes used (4.52%, out of 48807936)
20864 non-contiguous files (0.9%)
1884 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 2154021/1685/13
128999150 blocks used (66.08%, out of 195210139)
0 bad blocks
18 large files
1869601 regular files
282774 directories
10 character device files
1 block device file
5 fifos
4294963048 links
53513 symbolic links (50169 fast symbolic links)
14 sockets
------------
2164179 files
ここにデータ復旧へのより賢明なアプローチはありますか?助けてくれてありがとう。
答え1
以前は、このようにファイルを回復したことがあります。
ddrescue
(FreeBSDから呼び出される同様のプログラム)を使用してディスクイメージを作成しますrecoverdisk
。回復を試みる前にこれを実行してください。メッセージが表示されたら、fsck
「いいえ」と言って画像を作成します。
VM(VMWareまたはスナップショットがあるもの)を使用し、このイメージをVMにHDDディスクとしてマウントします。これにより、剪定の問題が回避されます。
- スナップショットを実行し、
fsck
保存できるすべてのファイルを実行してコピーします。fsck
回復不能なファイルの削除を要求します。 - スナップショットを復元し、ツールを使用する
fsck
前後に試してくださいe2undel
。 - もう一度復元して
ext4magic -M
オプションを試してください。 - 最後に
less -f /dev/sdb
知られているテキスト文字列が回復され、見つかります。注:時間が経つにつれて、これらの内容のいくつかのリビジョンを見つけることができます。これはすべて手動で行われます。