web-dev-qa-db-ja.com

破損したext3パーティションからデータを回復する方法は?

私のサーバーに何らかのドライブ障害があり、OS(CentOS 5)がクラッシュして動作を停止しました(起動を拒否します)。

そこで、OSが動作する別のドライブを置き、そこから古いドライブにパーティションをマウントしようとします。

ほとんどのパーティションは、MySQLテーブルが存在する/varパーティションを除いて、正常にマウントされます。
マウントしようとすると、dmesgで次のエラーが表示されます:

sd 0:0:1:0:未処理のセンスコード
sd 0:0:1:0:SCSIエラー:戻りコード= 0x08100002
結果:hostbyte = invalid driverbyte = DRIVER_SENSE、SUGGEST_OK
sdb:Current:sense key:Medium Error
追加。センス:未回復の読み取りエラー

情報fld = 0x4a47e
JBD:オフセット9863のブロックの読み取りに失敗しました
JBD:リカバリに失敗しました
EXT3-fs:ジャーナルの読み込みエラー。

そのパーティションのデータを回復する方法はありますか?


編集:
リクエストに応じて、tune2fs -l /dev/sdb2の出力は次のとおりです。

tune2fs 1.39 (29-May-2006)
Filesystem volume name:   /var1
Last mounted on:          <not available>
Filesystem UUID:          d84f5181-24f3-40ce-9eaa-601ae5ae33bd
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              26214400
Block count:              26214063
Reserved block count:     1310703
Free blocks:              25127226
Free inodes:              26213665
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1017
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         32768
Inode blocks per group:   1024
Filesystem created:       Thu May 13 18:14:28 2010
Last mount time:          Thu Nov 29 12:52:00 2012
Last write time:          Wed Mar 27 20:29:28 2013
Mount count:              15
Maximum mount count:      -1
Last checked:             Thu May 13 18:14:28 2010
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      35f38c48-3933-4c99-bde2-63b0eccf200d
Journal backup:           inode blocks

編集2:
@ Hartmutの提案に従い、fsck.ext3 /dev/sdb2を実行して次の結果を得ました。

e2fsck 1.39 (29-May-2006)
/var1: recovering journal
/var1: Attempt to read block from filesystem resulted in short read while reading block 11931

JBD: Failed to read block at offset 9863
fsck.ext3: No such device or address while trying to re-open /var1
e2fsck: io manager magic bad!
6
GetFree

ハードドライブに物理的な障害があり、ext3ジャーナルを含むブロックに影響しているようです。

このディスクのリカバリを実行するには、少なくとも故障したドライブパーティションと同じ大きさの2番目の空のハードドライブが必要です。リカバリしたファイルのコピー先も必要になるので、 3番目の空のハードドライブ、ネットワークファイル共有などと呼びます。

一般的な回復プロセスは次のようになります。

  1. dd conv=noerror以上のdd_rescueを使用して、障害が発生したパーティションを新しいドライブにコピーします。これには時間がかかる場合があります。

  2. コピーに対してさらにすべての操作を実行します。ここでは、/dev/sdb2/dev/sdc2にコピーし、ファイルを/dev/sdd2にリカバリするとします。

  3. ジャーナルは破損しているため、削除します。

    tune2fs -O ^has_journal /dev/sdc2
    
  4. 次に、デバイスのfsckを完了します。これには時間がかかる場合があります。

    e2fsck /dev/sdc2
    
  5. ファイルシステムを読み取り専用でマウントし、ファイルの回復を試みます。

    mount -o ro /dev/sdc2 /mnt/baddrive
    mount /dev/sdd2 /mnt/recoveredfiles
    cp -av /mnt/baddrive/* /mnt/recoveredfiles
    
  6. 元のディスクを再び使用することは決してありません。交換してください(保証期間中の場合は保証期間中)。

6
Michael Hampton

mount -t ext2 ...を使用してext2ファイルシステムとしてマウントしてみましたか? ext3はext2と下位互換性があるため、壊れているように見えるジャーナルを無視する必要があります。これは理想的なソリューションではありませんが、運が良ければ、一部のデータにアクセスできる場合があります。

2
fab4am

ファイルシステムのスーパーブロックが破損している可能性があります。以下の手順に従って、スーパーブロックを復元できます。

# dumpe2fs /dev/sdb2 | grep -i superblock

出力例:

Primary superblock at 0, Group descriptors at 1-6
Backup superblock at 32768, Group descriptors at 32769-32774
Backup superblock at 98304, Group descriptors at 98305-98310
Backup superblock at 163840, Group descriptors at 163841-163846
Backup superblock at 229376, Group descriptors at 229377-229382

代替スーパーブロックを使用してパーティションをfsckするか、ファイルシステムにfsckを使用せずに代替スーパーブロックを使用してパーティションをマウントすることができます。

ファイルシステムをチェックするには

# fsck.ext3 -b 32768 /dev/sda2

代替スーパーブロックでファイルシステムをマウントするには:

# mount sb={alternative-superblock} /dev/device /mnt
# mount sb=32768 /dev/sdb2 /mnt

ファイルを参照してみてください。

1
Amit Biyani