Recuperar dados disco EXT3 - SOLVED

zzz

Power Member
Tenho um disco externo de 250GB em EXT3, de um momento para o outro este dizia-me que estava sempre cheio.

Foi então que fiz da bonita, apaguei todas as pastas excepto a /home e agora nem monta

"Invalid argument" :mad:

Depois tentei correr este para recuperar, aparece aquelas janelas do realocate... (meto o -y para dizer sim a todas ) e parece que lixei o disco

Também tentei com o -n
Código:
e2fsck -n /dev/discs/disc0/part1
Código:
e2fsck: e2fsck_read_bitmaps: illegal bitmap block(s) for MyBook
Vou agora ver se consigo recuperar o disco com este programa: Stellar Phoenix Linux

é que tenho 250GB de dados e era um bocado chato perde-los:005:
 
Última edição:
Para quem utiliza o Windows, pode usar estes programas-----------------------
Também têm aqui alguma ajuda em PT:
http://www.guiadohardware.net/tutoriais/recuperando-particoes-corrigindo-sistemas-arquivos/

Se for uma partição EXT3, use o comando:
# fsck.ext3 /dev/hda1
Ele vai começar a apontar os erros e perguntar se cada um deve ser corrigido. Normalmente você pode ir apenas respondendo "y" para tudo, mas caso existam dados realmente importantes na partição é melhor prestar mais atenção. Arquivos danificados ou fragmentos de arquivos que puderam ser recuperados vão para a pasta "lost+found" no diretório raiz da partição.
Você pode também adicionar o parâmetro "-f", que força a verificação da partição, mesmo que o sistema de arquivos pareça não ter problemas:
# fsck.ext3 -f /dev/hda1
O fsck não é capaz de recuperar o sistema de arquivos em casos de problemas com o superbloco, o setor que contém informações essenciais, como o tipo, tamanho, status e informações sobre a estrutura do sistema de arquivos. Quando não encontra o superbloco, o fsck simplesmente falha miseravelmente, exibindo um "fatal error", sem maiores explicações.
É difícil estimar quantas reinstalações já foram feitas, e qual foi o efeito negativo sobre a reputação do sistema durante sua história por causa deste simples problema, que é felizmente fácil de resolver.
Sempre que a partição é criada, são criados vários superblocos alternativos, que servem justamente de backups para casos de problemas com o primeiro. Você pode ver a lista de endereços usando o comando "mkfs.ext3 -n partição", como em:
# mkfs.ext3 -n /dev/hda1
Ao usar o comando, nunca esqueça de incluir o "-n", caso contrário ao invés de mostrar as informações, ele vai formatar a partição. No final do relatório você encontra:
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736
Alternativamente, você pode usar também o comando "dumpe2fs /dev/hda1 | grep -i superblock". O Testdisk (que vimos a pouco) também oferece uma opção para listar superblocos alternativos em partições EXT, que você acessa em "Advanced > Superblock".
Chame novamente o comando "fsck.ext3", adicionando a opção "-b", seguida do endereço do superbloco que será usado. Caso eventualmente o primeiro resulte em erro, experimente o segundo, e assim por diante:
# fsck.ext3 -f -b 32768 /dev/hda2
Para partições EXT2, use o comando "fsck.ext2", que suporta os mesmos parâmetros.
 
puxa nem com os superblocos vou lá :(

Código:
 [admin@myasus root]$ fsck.ext3 -b 32768 /dev/discs/disc0/part5
e2fsck 1.38 (30-Jun-2005)
Inode table for group 0 is not in group.  (block 1177535144)
WARNING: SEVERE DATA LOSS POSSIBLE.
Relocate<y>? 

.....
e2fsck: e2fsck_read_bitmaps: illegal bitmap block(s) for MyBook
 
Somebody with the same problem resolved this way:

http://shon.org/blog/?p=25
[root@adrock init.d]# dd if=/dev/ida/c0d0p7 of=/big/var.bak.dd
530368+0 records in

Still hosed, but now I have a backup of the burnination. And now for the FIX!!!

mke2fs -S /dev/ida/c0d0p7
mke2fs 1.27 (8-Mar-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
66528 inodes, 265184 blocks
13259 blocks (5.00%) reserved for the super user
First data block=1
33 block groups
8192 blocks per group, 8192 fragments per group
2016 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185

Writing superblocks and filesystem accounting information: done

That did it! mke2fs re-wrote all of the superblocks and group descriptors and I was able to mount in RO mode and copy off the data. After that I was able to fsck and remount the original parition with no problems!


other case:
http://user-mode-linux.sourceforge.net/old/sdotm.html
 
E FINALMENTE CONSEGUI (parte :( )

Solução (façam backups se puderem :P)
mke2fs -S /dev/ida/c0d0p7

fsck ...

mount


:D



bahh :014:
parece que só recuperou alguns ficheiros...
posso ver as pastas mas algumas dão erro ao entrar
 
Última edição:
Só para avisar que o FSCK do RIP live cd está marado, dava sempre segmentation fault.
Assim corri na maquina virtual o ubuntu e já deu.

Passado uma noite a correr o fsck -yf
Parece ter recuperado tudo, o problema foi que grande parte das coisas ficaram com o nome todo alterado #768768586 .....

Instalei o TreeSize Pro, e agora já vejo os ficheiros com o tamanho, posso ver +/- que tipo de ficheiro era e depois mudar o nome.

Puxa foi dificil mas acho que já tá :)
Agora
 
Back
Topo