web-dev-qa-db-ja.com

ext4スーパーブロックの回復

最近、外付けハードドライブエンクロージャが故障しました（ハードドライブ自体が別のエンクロージャで起動します）。ただし、その結果、EXT4ファイルシステムが破損しているように見えます。

ドライブには単一のパーティションがあり、GPTパーティションテーブル（ラベルears）を使用します。

fdisk -l /dev/sdbは以下を示します：

   Device Boot      Start         End      Blocks   Id  System
     /dev/sdb1          1  1953525167   976762583+  ee  GPT

testdiskは、パーティションが無傷であることを示しています。

1 P MS Data                     2049 1953524952 1953522904 [ears]

...しかし、パーティションはマウントに失敗します：

$ Sudo mount /dev/sdb1 a
mount: you must specify the filesystem type
$ Sudo mount -t ext4 /dev/sdb1 a 
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,

fsckは無効なスーパーブロックを報告します：

$ Sudo fsck.ext4 /dev/sdb1            
e2fsck 1.42 (29-Nov-2011)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/sdb1

およびe2fsckは同様のエラーを報告します。

$ Sudo e2fsck /dev/sdb1        
Password: 
e2fsck 1.42 (29-Nov-2011)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

dumpe2fsも：

$ Sudo dumpe2fs /dev/sdb1                      
dumpe2fs 1.42 (29-Nov-2011)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdb1

mke2fs -n（注、-n）はスーパーブロックを返します。

$ Sudo mke2fs -n /dev/sdb1       
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61054976 inodes, 244190363 blocks
12209518 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
7453 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

...しかし、各ブロックに対して「e2fsck -b [block]」を試行すると失敗します。

$ Sudo e2fsck -b 71663616 /dev/sdb1 
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1

しかし、私が理解しているように、これらはファイルシステムが作成されたときにスーパーブロックがあった場所であり、必ずしもそれらがまだ完全であるとは限りません。

誰かがログを解読できる場合は、testdiskdeep search も実行しました。それは次のような多くのエントリに言及しています

recover_EXT2: s_block_group_nr=1/7452, s_mnt_count=6/20,
s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 244190363
recover_EXT2: part_size 1953522904
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed

これらの値でe2fsckを実行すると、次のようになります。

e2fsck: Bad magic number in super-block while trying to open /dev/sdb1

私はtestdisk.logのすべてのスーパーブロックでそれを試しました

for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
   Sudo e2fsck -b $i -B 4096 /dev/sdb1
done

...すべて同じe2fsckエラーメッセージが表示されます。

私の最後の試みでは、別のファイルシステムのオフセットを試しました。オフセットiごとに、iは31744、32768、1048064、1049088のいずれかです。

$ Sudo losetup -v -o $i /dev/loop0 /dev/sdb

... testdisk /dev/loop0を実行していて、興味深いものは見つかりませんでした。

私はかなり徹底的でしたが、低レベルのファイル回復ツール（foremost/photorec）に頼ることなくファイルシステムを回復する方法はありますか？

filesystemsdata-recoveryext4superblock
51
tlvince

残念ながら、私はファイルシステムを回復できず、低レベルのデータ回復手法（Ubuntuの Data Recovery wikiエントリにうまくまとめられています）に頼らなければなりませんでした。そのうち Sleuth Kit 最も有用であることがわかった。

清潔のために回答済みとマーク。

17
tlvince

これはすでに古いかもしれませんが、いくつかの提案：

testdiskが主張するように、元のブロックサイズが4096であることが確実である場合は、mke2fs -Sを使用してディスク上のスーパーブロックを書き換えることができます。男から：

   -S    Write  superblock and group descriptors only.  This is useful if all
          of the superblock and backup superblocks are corrupted, and a  last-
          ditch  recovery method is desired.  It causes mke2fs to reinitialize
          the superblock and group descriptors, while not touching  the  inode
          table and the block and inode bitmaps.  The e2fsck program should be
          run immediately after this option is used, and there is no guarantee
          that  any  data  will be salvageable.  It is critical to specify the
          correct filesystem blocksize when using this option, or there is  no
          chance of recovery.

正しいブロックサイズがわからない場合は、mke2fs -n -b 2048 /dev/sdb1を使用して、このコマンドが提供するすべてのスーパーブロックバックアップを試してください。その後、同じですが最後のブロックサイズ1024を使用します。

10
Jari Laamanen

前述のように、おそらく古くなっていますが、fdisk（AFAIK）はGPTディスクをサポートしていません。 partedなどのツールを使用する必要があります。

Debian squeeze（カーネル2.6.32-5-486）を実行する仮想マシンをテストし、partedを使用して仮想ディスクをGPTとしてフォーマットしました...

# parted /dev/sde
(parted) mklabel GPT
(parted) mkpart part1 0 10G
(parted) quit
# fdisk -l /dev/sde
.
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
.
Disk /dev/sde: 85.9 GB, 85899345920 bytes
 255 heads, 63 sectors/track, 10443 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
. 
   Device Boot      Start         End      Blocks   Id  System
/dev/sde1               1       10444    83886079+  ee  GPT

これはfdiskバージョン2.17.2（util-linux-ng）です。

mkfsとfsckは「実際の」パーティションを問題なくピックアップするはずですが、GPTパーティションテーブルが破損していないことを確認するには、GNU parted。

1
StarNamer

コンピュータを再起動した後、同じマウントの問題が発生しました。私の場合、partedを実行して次のようなコマンドを発行するだけで十分です。

set 1 lvm on

その後、終了して再マウントしてください。多分それはまたあなたを助けるでしょう。

0
user30192