Recentemente, meu gabinete de disco rígido externo falhou (o próprio disco rígido é ligado em outro gabinete). No entanto, como resultado, parece que seu sistema de arquivos EXT4 está corrompido.
A unidade possui uma única partição e usa uma tabela de partição GPT (com o rótulo ears).
fdisk -l /dev/sdb mostra:
Device Boot Start End Blocks Id System
/dev/sdb1 1 1953525167 976762583+ ee GPT
testdisk mostra que a partição está intacta:
1 P MS Data 2049 1953524952 1953522904 [ears]
... mas a partição falha ao montar:
$ 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 relata um superbloco inválido:
$ 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
e e2fsckrelata um erro semelhante:
$ 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 Além disso:
$ 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(note -n) retorna os superblocos:
$ 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
... mas tentar "e2fsck -b [block]" para cada bloco falha:
$ sudo e2fsck -b 71663616 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1
No entanto, pelo que entendi, é aqui que estavam os superblocos quando o sistema de arquivos foi criado, o que não significa necessariamente que eles ainda estão intactos.
Também fiz uma testdisk pesquisa profunda, se alguém puder decifrar o log. Menciona muitas entradas como:
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
A execução do e2fsck com esses valores fornece:
e2fsck: Bad magic number in super-block while trying to open /dev/sdb1
Eu tentei isso com todos os superblocos no testdisk.log
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
sudo e2fsck -b $i -B 4096 /dev/sdb1
done
... tudo com a mesma e2fsckmensagem de erro.
Na minha última tentativa, tentei diferentes deslocamentos do sistema de arquivos. Para cada deslocamento i, em que ié um dos 31744, 32768, 1048064, 1049088:
$ sudo losetup -v -o $i /dev/loop0 /dev/sdb
... e correndo testdisk /dev/loop0, não achei nada de interessante.
Fui bastante exaustivo, mas existe alguma maneira de recuperar o sistema de arquivos sem recorrer a ferramentas de recuperação de arquivos de baixo nível ( foremost/ photorec)?
fonte
sudo fdisk -l /dev/sdbmostra?testdisk, como mencionado acima, tentei diferentes compensações usandolosetup(i * 512ondeié um dos 62, 64, 2047 ou 2049).Respostas:
Infelizmente, não consegui recuperar o sistema de arquivos e tive que recorrer a técnicas de recuperação de dados de nível inferior (resumidas na entrada wiki do Data Recovery do wiki), das quais o Sleuth Kit se mostrou mais útil.
Marcação como respondida por motivos de limpeza.
fonte
Isso já pode estar desatualizado, mas algumas sugestões:
Se você tiver certeza absoluta de que o tamanho do bloco original é 4096, conforme reivindicado por
testdisk, poderá reescrever os superblocos no disco usandomke2fs -S. Do homem:Se você não tiver certeza sobre o tamanho do bloco correto, use
mke2fs -n -b 2048 /dev/sdb1e tente todos os backups de superblocos que este comando fornece e, depois disso, o mesmo, mas usando o último tamanho do bloco 1024.fonte
Como mencionado, provavelmente desatualizado, mas o fdisk (AFAIK) não suporta discos GPT. Você precisa usar uma ferramenta separada ou outra.
Acabei de testar uma máquina virtual executando o Debian squeeze (kernel 2.6.32-5-486) e formatado um disco virtual como GPT usando parted ...
Esta é a versão 2.17.2 do fdisk (util-linux-ng).
mkfs e fsck devem pegar a partição 'real' OK, mas para verificar se a tabela de partição GPT não está corrompida, você deve ter usado o GNU parted.
fonte
Eu tive o mesmo problema de montagem depois de reiniciar o computador. No meu caso, foi o suficiente para executar parted e emitir um comando como:
e saia e tente remontar. Talvez isso ajude você também.
fonte