Existe um comando para recuperar / recuperar arquivos apagados excluídos rm
?
$ rm -rf /path/to/myfile
Como posso me recuperar myfile
? Se existe uma ferramenta, como posso usá-la?
Existe um comando para recuperar / recuperar arquivos apagados excluídos rm
?
$ rm -rf /path/to/myfile
Como posso me recuperar myfile
? Se existe uma ferramenta, como posso usá-la?
Respostas:
O link fornecido por alguém nos comentários provavelmente é sua melhor chance.
Linux debugfs Hack: Undelete Files
Esse artigo, embora pareça um pouco intimidador, é realmente bastante simples de seguir. Em geral, as etapas são as seguintes:
Use debugfs para visualizar um log do sistema de arquivos
$ debugfs -w /dev/mapper/wks01-root
No prompt debugfs
debugfs: lsdel
Saída de amostra
Inode Owner Mode Size Blocks Time deleted
23601299 0 120777 3 1/ 1 Tue Mar 13 16:17:30 2012
7536655 0 120777 3 1/ 1 Tue May 1 06:21:22 2012
2 deleted inodes found.
Execute o comando no debugfs
debugfs: logdump -i <7536655>
Determinar arquivos inode
...
...
....
output truncated
Fast_link_dest: bin
Blocks: (0+1): 7235938
FS block 7536642 logged at sequence 38402086, journal block 26711
(inode block for inode 7536655):
Inode: 7536655 Type: symlink Mode: 0777 Flags: 0x0 Generation: 3532221116
User: 0 Group: 0 Size: 3
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
atime: 0x4f9fc730 -- Tue May 1 06:21:20 2012
mtime: 0x4f9fc72f -- Tue May 1 06:21:19 2012
dtime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
Fast_link_dest: bin
Blocks: (0+1): 7235938
No magic number at block 28053: end of journal.
Com as informações do inode acima, execute os seguintes comandos
# dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
# file recovered.file.001
file: ASCII text, with very long lines
Arquivos foram recuperados para recovered.file.001
.
Se o exposto acima não é para você, usei ferramentas como photorec
a de recuperar arquivos no passado, mas é voltado apenas para arquivos de imagem. Eu escrevi sobre esse método extensivamente no meu blog neste artigo intitulado:
debugfs -w /dev/sdb2
mas lsdel
sais:0 deleted inodes found.
extundelete
é mais fácil para o ext3 / 4 e provavelmente levaria aos mesmos resultados.
/dev/mapper/wks01-root: No such file or directory while opening filesystem
onde você tirou isso /dev/mapper/wks01-root
?
Com algumas chances, às vezes posso recuperar arquivos excluídos com esse script ou com a próxima solução na resposta:
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:\n\n\t$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk '{print $9}')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
Há outro truque útil: se você conhece um padrão nos arquivos excluídos, digite alt+ sys+ resuopara reiniciar + remontar em somente leitura e, em um live-cd, use grep
para pesquisar no disco rígido:
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
edite /tmp/recover
para manter apenas o (s) seu (s) arquivo (s) antes.
Ei, se com a filosofia unix tudo são arquivos, é hora de tirar vantagem disso, não?
grep
solução baseada é muito inteligente e funcionou para mim, mesmo com o sistema de arquivos ainda montado. Obrigado!
grep -av "[^[:print:]]"
grep
solução funcionou para mim com uma modificação: fiz sudo grep --line-buffered -ab "$PATTERN" /dev/sda1 | tee lines
e obtive desvios de bytes (como 123123123:line\n456456456:another\n...
), depois fiz n=1000; sudo dd of=before if=/dev/sda1 ibs=1 skip=$[123123123-$n] count=$n
e n=1000; sudo dd of=after if=/dev/sda1 ibs=1 skip=123123123 count=$n
com n
valores diferentes .
O que funcionou para mim foi dado pelo arch (aplica-se apenas a arquivos de texto):
grep -a -C 200 -F 'Unique string in text file' /dev/sdXN
Onde /dev/sdXN
está a partição que contém o arquivo perdido (verifique mount
se não tiver certeza).
Demora um pouco, mas funcionou quando excluí acidentalmente algum código-fonte que ainda não havia confirmado!
rm data/*.json python myFile.py
em vez derm data/*.json && python myFile.py
/dev/sdXN
é para o sistema de arquivos, certo? Eu encontrei o meu comdf -T | awk '{print $1,$2,$NF}' | grep "^/dev"
grep: conflicting matchers specified
Embora esta questão tenha sido resolvida e tenha alguns anos, quero mencionar o utilitário testdisk .
Como recuperar arquivos com o testdisk é explicado bem neste tutorial . Para recuperar arquivos, execute testdisk /dev/sdX
e selecione seu tipo de tabela de partição. Depois disso, selecione [ Advanced ] Filesystem Utils
, escolha sua partição e selecione [Undelete]
. Agora você pode procurar e selecionar arquivos excluídos e copiá-los para outro local no seu sistema de arquivos.
Eu tive o mesmo problema na semana passada e tentei muitos programas, como debugfs, photorec, ext3grep e extundelete. O ext3grep foi o melhor programa para recuperar arquivos. A sintaxe é muito fácil:
ext3grep image.img --restore-all
ou:
ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’
Este vídeo é um mini tutorial que pode ajudá-lo.
Uma alternativa pode estar usando, em del
vez de rm
excluir:
http://fex.belwue.de/fstools/del.html
del
possui uma função de exclusão e funciona com qualquer sistema de arquivos.
Claro que não é uma solução se você já excluiu seus arquivos com "não faça prisioneiros" rm: -}
del
comando.
conecte a unidade através da interface externa
umount /dev/{sd*}
extundelete --restore-all /dev/{sd*}
Veja este link para mais informações: cancele a exclusão de um arquivo recém-excluído no ext4 com extundelete .
Ferramentas de recuperação - linha de comando:
Ferramentas de recuperação - Gui:
Informações:
Na minha experiência pessoal, recupero meus dados usando o ufs-explorer e o photorec
(1) = Não é de código aberto, não é livre
(2) = Não é de código aberto, gratuito
(3) = Código aberto e gratuito
(4) = Ter suporte a NTFS
(5) = Possui recurso de estrutura de diretório
Discordo que é impossível, apenas muito, muito difícil, e também nunca fiz isso no Linux:
Quando os arquivos são excluídos, eles não são realmente excluídos. O que acontece é que o espaço em que estavam no disco rígido é redefinido, de modo que, se o computador tentar gravar dados lá, nada reclamará. Geralmente, os dados do disco rígido que você pensou que excluiu podem estar lá quase um ano depois. Ou pelo menos, esta é minha experiência em uma máquina Windows. Se funciona ou não da mesma maneira em uma linha de comando no Linux, não tenho certeza, mas você provavelmente precisará de um Live CD separado para abrir a partição assim, e também não há garantia de que os arquivos ainda estejam lá. Eu fiz isso no Windows XP várias vezes usando o Zero Assumption Recovery. Tenho certeza de que existe uma ferramenta semelhante ao redor, se você se esforçar o suficiente.
Quando você exclui um arquivo, a contagem de links na tabela de inodes para esse arquivo diminui em um. No Unix, quando a contagem de links cai para 0, os blocos de dados para esse arquivo são marcados como livres e, geralmente, as referências a esses blocos são perdidas. Acabei de descobrir no comentário do @ fedorqui que pode haver alguma maneira de acessar esses blocos, mas isso só é aplicável ao sistema de arquivos ext3.
Uma maneira de preservar os arquivos será escrever uma função que permita mover os arquivos para uma área de lixo (digamos $HOME/.trash
) e recuperar os arquivos necessários a partir daí. Esta função pode ser associada a rm
. Você pode agendar um trabalho cron para excluir os arquivos que estão na área de lixo por um determinado número de dias.
Isso pode salvar o problema para alguns de vocês.
Se você já usou o gedit para editar esse arquivo, por padrão, uma cópia desse arquivo será criada.
Por exemplo, suponha que tenhamos excluído acidentalmente 'myfile.txt'.
Na pasta que costumava conter o arquivo que você acabou de excluir, use estes comandos e você recuperará a cópia a partir daí:
ls | grep 'myfile.txt~'
Com um pouco de sorte, você o encontrará e depois:
cp 'myfile.txt~' 'myfile.txt'
Eu recuperei um arquivo agora usando esse método. Boa sorte!