www.kadu.langoni.net

Outro dia recebi uma ligação de um cliente com problemas em um servidor. Ele já havia tentado o que sabia mas o GRUB não parava de exibir um "error 24". Fizemos um boot com um CD do Debian, alterando a prioridade do debconf e ativando o network-console, deste modo consegui remotamente acessar o servidor.

De cara tentei o de praxe, fsck, mas o resultado foi preocupante. Eu obtive a seguinte mensagem:
# fsck /dev/hdc1
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
fsck.ext3: Filesystem revision too high while trying to open /dev/hdc1
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

Primeiro pensei que a versão do FSCK pudesse ser muito antiga e por isso não estivesse conseguindo ler a partição, então adicionamos o disco defeituoso em uma máquina com Debian Lenny instalado, mas a mensagem persistiu. Então tentei fazer o que se pedia no erro acima:
# e2fsck -b 8193 /dev/hdc1
e2fsck 1.39 (29-May-2006)
fsck.ext3: Bad magic number in super-block while trying to open /dev/hdc1

The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193

Já estava pronto para condenar o disco, mas a persistência, que não me falta, me fez pedir mais um tempo.
Então encontrei uma thread[1] de uma lista de discussão que relatava o mesmo problema, e a solução do cara foi muito inteligente.
Eu nunca copiei os dados resultantes do mke2fs que reportam os superblocks de backup, e lógico não teria como utilizar estes dados para recuperação. Mas o usuário da lista que estava com o problema teve a brilhante idéia de realizar um mke2fs com a opção -n (apenas simula a formatação) e utilizar os dados resultantes para tentar recuperar o superblock de backup.
O Resultado foi exatamente o que eu precisava para recuperar o filesystem:
# mke2fs -n -j /dev/hdc1
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
4889248 inodes, 9767512 blocks
488375 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
299 block groups
32768 blocks per group, 32768 fragments per group
16352 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
4096000, 7962624

Peguei o primeiro superblock e executei
e2fsck -b 32768 /dev/hdc1

Depois disso realizei um fsck na partição, houve muita perda de dados, mas consegui deixar o filesystem estável a ponto de conseguir recuperar dados. Para variar não haviam backups do servidor, mas no lost+found consegui recuperar o banco de dados de autenticação do squid, o script do firewall e os arquivos de configuração do squid, ou seja, tudo o que precisava para refazer o servidor.

Os arquivos foram reutilizados e duas horas depois a máquina estava no ar, pronta para operar.

Resolvi fazer este post pois acredito que poderá ajudar a outras pessoas em situações semelhantes algum dia.
Abraços a todos!

[1]http://linux.derkeiler.com/Mailing-Lists/Fedora/2007-04/msg02365.html