Como recuperar dados de uma partição ext3 corrompida?

Question

Um servidor meu teve uma falha de disco de algum tipo que fez com que o sistema operacional (CentOS 5) falhasse e parasse de funcionar (ele se recusa a inicializar).

Então colocamos outra unidade com um sistema operacional em funcionamento e a partir daí tentamos montar as partições na unidade antiga.

A maioria das partições é bem montada, exceto por uma: a partição /var , onde residem as minhas tabelas MySQL.
Quando tento montar esse, vejo esses erros com dmesg :

sd 0:0:1:0: Unhandled sense code
sd 0:0:1:0: SCSI error: return code = 0x08100002
Result: hostbyte=invalid driverbyte=DRIVER_SENSE,SUGGEST_OK
sdb: Current: sense key: Medium Error
Add. Sense: Unrecovered read error

Info fld=0x4a47e
JBD: Failed to read block at offset 9863
JBD: recovery failed
EXT3-fs: error loading journal.

Existe uma maneira de recuperar os dados nessa partição?

EDITAR:
Conforme solicitado, a saída de 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

EDIT 2:
Como sugerido por @Hartmut, eu corro fsck.ext3 /dev/sdb2 com o seguinte resultado:

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!

    

Answer 1

Parece que seu disco rígido teve uma falha física e afetou um bloco contendo o diário ext3.

Você precisará de um segundo disco rígido em branco, pelo menos tão grande quanto a partição da unidade com falha, para executar qualquer tipo de recuperação desse disco. Você também precisará de um destino para copiar os arquivos recuperados para , então vamos chamá-lo de um terceiro disco rígido em branco, compartilhamento de arquivos de rede, etc.

O processo geral de recuperação será:

1. Copie a partição com falha para a nova unidade usando dd conv=noerror ou melhor dd_rescue . Isso pode levar algum tempo.

2. Executar todas as operações adicionais na cópia Aqui, presumo que você tenha copiado /dev/sdb2 para /dev/sdc2 e que você recuperará arquivos para /dev/sdd2 .

3. Como o diário está corrompido, nós o removeremos:

   tune2fs -O ^has_journal /dev/sdc2
   

4. Agora complete um fsck do dispositivo. Isso pode levar algum tempo.

   e2fsck /dev/sdc2
   

5. Monte o sistema de arquivos somente leitura e tente recuperar arquivos.

   mount -o ro /dev/sdc2 /mnt/baddrive
   mount /dev/sdd2 /mnt/recoveredfiles
   cp -av /mnt/baddrive/* /mnt/recoveredfiles
   

6. Em nenhum caso você deve usar o disco original novamente. Substitua-o (dentro da garantia, se ainda estiver na garantia).

Answer 2

Você tentou montá-lo como sistema de arquivos ext2 com mount -t ext2 ... ? O ext3 é retrocompatível com o ext2, por isso deve simplesmente ignorar o diário que parece estar quebrado. Não é uma solução ideal, mas pode permitir que você acesse alguns dados se tiver sorte!

    

Answer 3

Pode ser possível que superblocos de sistemas de arquivos tenham sido corrompidos. Você pode seguir os passos abaixo para recuperar os superblocos.

# dumpe2fs /dev/sdb2 | grep -i superblock

Exemplo de saída:

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

Ou você pode fsck a partição com superbloco alternativo ou você pode montar a partição com superbloco alternativo sem fsck no sistema de arquivos.

Para verificar o sistema de arquivos

# fsck.ext3 -b 32768 /dev/sda2

Para montar o sistema de arquivos com o superbloco alternativo:

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

e tente procurar arquivos.