私のサーバーに何らかのドライブ障害があり、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!
ハードドライブに物理的な障害があり、ext3ジャーナルを含むブロックに影響しているようです。
このディスクのリカバリを実行するには、少なくとも故障したドライブパーティションと同じ大きさの2番目の空のハードドライブが必要です。リカバリしたファイルのコピー先も必要になるので、 3番目の空のハードドライブ、ネットワークファイル共有などと呼びます。
一般的な回復プロセスは次のようになります。
dd conv=noerror
以上のdd_rescue
を使用して、障害が発生したパーティションを新しいドライブにコピーします。これには時間がかかる場合があります。
コピーに対してさらにすべての操作を実行します。ここでは、/dev/sdb2
を/dev/sdc2
にコピーし、ファイルを/dev/sdd2
にリカバリするとします。
ジャーナルは破損しているため、削除します。
tune2fs -O ^has_journal /dev/sdc2
次に、デバイスのfsckを完了します。これには時間がかかる場合があります。
e2fsck /dev/sdc2
ファイルシステムを読み取り専用でマウントし、ファイルの回復を試みます。
mount -o ro /dev/sdc2 /mnt/baddrive
mount /dev/sdd2 /mnt/recoveredfiles
cp -av /mnt/baddrive/* /mnt/recoveredfiles
元のディスクを再び使用することは決してありません。交換してください(保証期間中の場合は保証期間中)。
mount -t ext2 ...
を使用してext2ファイルシステムとしてマウントしてみましたか? ext3はext2と下位互換性があるため、壊れているように見えるジャーナルを無視する必要があります。これは理想的なソリューションではありませんが、運が良ければ、一部のデータにアクセスできる場合があります。
ファイルシステムのスーパーブロックが破損している可能性があります。以下の手順に従って、スーパーブロックを復元できます。
# 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
ファイルを参照してみてください。