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 tem 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 não é montada:
$ 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 informa 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 e2fsck informam 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 também:
$ 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 (nota, -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 tentando "e2fsck -b [block]" para cada bloco falhar:
$ sudo e2fsck -b 71663616 /dev/sdb1
e2fsck 1.42 (29-Nov-2011)
e2fsck: Invalid argument while trying to open /dev/sdb1
No entanto, como eu entendo, estes são os lugares onde os superblocos estavam quando o sistema de arquivos foi criado, o que não significa necessariamente que eles ainda estão intactos.
Eu também executei uma% <> href="https://gist.github.com/1961186"> busca 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
for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4); do
sudo e2fsck -b $i -B 4096 /dev/sdb1
done
... todos com a mesma mensagem de erro testdisk.log .
Na minha última tentativa, tentei diferentes deslocamentos do sistema de arquivos. Para cada deslocamento e2fsck , em que i é um dos 31744, 32768, 1048064, 1049088:
$ sudo losetup -v -o $i /dev/loop0 /dev/sdb
... e executando i , não achei nada interessante.
Eu tenho sido bastante exaustivo, mas existe qualquer maneira para recuperar o sistema de arquivos sem recorrer a ferramentas de recuperação de arquivos de baixo nível ( testdisk /dev/loop0 / foremost )?
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 (bem resumidas nos Dados do Ubuntu. Recovery na wiki), dos quais o Sleuth Kit se mostrou mais útil.
Marcando como respondido por causa da limpeza.
Isso já pode estar desatualizado, mas algumas sugestões:
Se você tiver certeza absoluta de que o tamanho original do bloco é 4096, conforme reivindicado por testdisk ,
você pode reescrever os superblocos no disco usando mke2fs -S . Do homem:
-S Write superblock and group descriptors only. This is useful if all
of the superblock and backup superblocks are corrupted, and a last-
ditch recovery method is desired. It causes mke2fs to reinitialize
the superblock and group descriptors, while not touching the inode
table and the block and inode bitmaps. The e2fsck program should be
run immediately after this option is used, and there is no guarantee
that any data will be salvageable. It is critical to specify the
correct filesystem blocksize when using this option, or there is no
chance of recovery.
Se você não tiver certeza sobre o tamanho correto do bloco, use mke2fs -n -b 2048 /dev/sdb1 e tente todos os backups de superblocos que este comando fornece, e depois o mesmo, mas usando o último bloco de tamanho 1024.
Como mencionado, provavelmente desatualizado, mas o fdisk (AFAIK) não suporta discos GPT. Você precisa usar parted ou alguma outra ferramenta.
Eu apenas testei uma máquina virtual rodando o Debian squeeze (kernel 2.6.32-5-486) e formatei um disco virtual como GPT usando o parted ...
# parted /dev/sde
(parted) mklabel GPT
(parted) mkpart part1 0 10G
(parted) quit
# fdisk -l /dev/sde
.
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.
.
Disk /dev/sde: 85.9 GB, 85899345920 bytes
255 heads, 63 sectors/track, 10443 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
.
Device Boot Start End Blocks Id System
/dev/sde1 1 10444 83886079+ ee GPT
Esta é a versão 2.17.2 do fdisk (util-linux-ng).
mkfs e fsck devem pegar a partição 'real', mas para checar se a tabela de partição GPT não está corrompida, você deve ter usado o GNU parted.
Eu tenho o mesmo problema de montagem depois de reiniciar o computador. No meu caso, foi o suficiente para executar parted e emitir um comando como:
set 1 lvm on
e, em seguida, saia e tente remontar. Talvez te ajude também.