Perguntas & Respostas

Vamos agora descrever a segunda maneira de recuperar os dados. Essa é a mais recomendada e eficiente. O maior benefício desse metodo é que você consegue recuperar arquivos com mais que 12 blocos.

Quando se trata de arquivos grandes, esse metodo é o único eficiente. Sugiro que faça uma imagem do seu device de disco em outra partição, para que se houver algum problema, você não perder todos os dados. Para isso:

# cp /dev/hda5 /root/working
#mount -t ext2 -o loop /root/working /mnt

Isso garante que você tenha um backup completo da sua partição, caso destrua completamente seu filesystem e possa voltar-lo.

Feito isso, você deve estar em dúvida para a situação de havendo apenas uma particação no seu disco, e ela no mode read-only, como se poderia recuperar o arquivo apagado? Se você possui várias partições, esse problema está solucionado. Mas se você possui apenas uma partição root e não tem nem partições MS-DOS para usar, voce vai precisar criar um ramdisk. Para usar ramdisk você deve seguir os passos:

# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
#mke2fs -v -m 0 /dev/ram0 2048
#mount -t ext2 /dev/ram0 /mnt

Isso vai criar um ramdisk de 2MB e montá-lo no diretório /mnt.

Não desmonte esse ramdisk até que todo conteúdo dele seja copiado para uma unidade validade (não volátil). Você pode perder todo o seu trabalho.

Caso tenha alguma unidade ZIP, essa é uma boa escolha, não precisando usar ramdisk.

O nosso próximo passo é perguntar para o filesystem quais os inodes que foram recentemente liberados (apagados). Para isso deve-se utilizar o programa chamado 'debugfs'. Inicie o programa seguido da partição que voce perdeu os arquivos.

# debugfs /dev/hda5

Se você deseja modificar os inodes diretamente, use a opção '-w' para possibilitar acesso de escrita.

# debugfs -w /dev/hda5

O comando para listar os últimos inodes apagados é:

debugfs: lsdel

Isso pode levar alguns segundos (ou minutos), e voce vai sentir que seu HD está em super atividade. Voce vai receber uma lista enorme. Deve ficar claro que voce precisa gravar isso em algum arquivo para poder analisar, para isso:

debugfs: quit # echo lsdel | debugfs /dev/hda5 > path/para/lsdel.out

lsdel.out deve estar em uma partição com direito de escrita, já que a /dev/hda5 está read-only.

Agora vem a parte mágica do trabalho, você deve pegar essa lista e analisar com calma, e anotar os inodes baseados exclusivamente nas informações que lhe são possíveis: hora que o inode foi apagado, o tamanho, o tipo, e números que indicam permissões e owner do inode. Se você tiver apagado esse arquivo a pouco tempo, não vai haver grande dificuldade.

O debugfs tem um comando que permite você ter mais detalhes sobre os inodes. Quando você tiver uma lista com todos inodes que você quer recuperar tente o comando: (estou supondo que estou interessado no inode 148003.

debugfs: stat <148003>
Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 6065
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount:
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 2000
atime: 0x31a21dd1 -- Tue May 21 20:47:29 2000
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 2000
dtime: 0x31a9a574 -- Mon May 27 13:52:04 2000
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6

Se você possui muitos inodes para verificar, tente o comando abaixo:

# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > path/para/inodes

Vai gerar o arquivo inodes, que vai conter apenas o número dos inodes para recuperar, um por linha. Esse arquivo vai ser útil então para usarmos neste novo comando, para obter os dados extendidos de cada inodes:

# sed 's/^.*$/stat <{RESPOSTA}>/' inodes | debugfs /dev/hda5 > path/to/stats

O arquivo stats contém toda informação necessária de cada inode.

Agora com base nestas informações e sabendo quais inodes queremos recuperar vamos enfim recuperar os dados.

Arquivos pequenos (menos de 12 blocks)
Se o arquivo possui menos de 12 blocks, toda a sequência de blocos desse arquivo está gravada dentro de um inode. debugfs tem um comando que permite você recuperar esse arquivo automaticamente. Vamos mostrar abaixo.

Primeiro fazemos o stat denovo:

debugfs: stat <148003>
Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 6065
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 12
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x31a9a574 -- Mon May 27 13:52:04 1996
atime: 0x31a21dd1 -- Tue May 21 20:47:29 1996
mtime: 0x313bf4d7 -- Tue Mar 5 08:01:27 1996
dtime: 0x31a9a574 -- Mon May 27 13:52:04 1996
BLOCKS:
594810 594811 594814 594815 594816 594817
TOTAL: 6

O arquivo tem 6 blocos, podemos mandar o debugfs grava-lo no arquivo, recovered.000:

debugfs: dump <148003> /mnt/recovered.000

Podemos imaginar que deva existir algum lixo no final do arquivo, se ele não ocupar perfeitamente o tamanho de um bloco. Mas isso pode ser facilmente retificado, por temos o tamanho real do arquivo nas informações do stat, então podemos usar o comando abaixo para gerar um novo arquivo, agora com tamanho real:

# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065

O novo arquivo /mnt/resized.000 foi gerado, se ele não tiver sido sobre escrito, ele estará idêntico ao original. Para evitar a perda do arquivo, o quanto mais rápido voce fizer o unmount, menos danos voce terá.

estou terminando o artigo em breve ele estara on line ...

ja usei isso aq... naum funfo...

meu sistema de arquivo é ext3!!!

intaum amigo ... acho q fud. ...