Os arquivos sobrescritos podem ser recuperados?

Question

Eu não estou falando sobre recuperar arquivos deletados , mas arquivos sobrescritos . Ou seja, pelos seguintes métodos:

# move
mv new_file old_file

# copy
cp new_file old_file

# edit
vi existing_file
> D
> i new_content
> :x

É possível recuperar alguma coisa se alguma das três ações acima for executada, supondo que nenhum programa especial esteja instalado na máquina linux?

    

Answer 1

A resposta é "Provavelmente sim, mas depende do tipo de sistema de arquivos e do tempo".

Nenhum desses três exemplos sobrescreverá os blocos de dados físicos de old_file ou existing_file, exceto por acaso.

• mv new_file old_file . Isso irá desvincular o old_file. Se houver hard links adicionais para old_file, os blocos permanecerão inalterados nos links restantes. Caso contrário, os blocos geralmente (dependendo do tipo de sistema de arquivos) serão colocados em uma lista livre. Em seguida, se o mv exigir cópia (ao contrário de apenas mover entradas de diretório), novos blocos serão alocados como mv gravações.

  Esses blocos recém-alocados podem ou não ser os mesmos que foram liberados . Em sistemas de arquivos como o UFS , blocos são alocados, se possível, a partir do mesmo grupo de cilindros que o diretório no qual o arquivo foi criado. Portanto, há uma chance de que desvincular um arquivo de um diretório e criar um arquivo nesse mesmo diretório reutilize (e sobrescreva) alguns dos mesmos blocos que foram liberados. É por isso que o conselho padrão para as pessoas que acidentalmente removem um arquivo é não gravar novos dados em arquivos em sua árvore de diretórios (e preferencialmente não em todo o sistema de arquivos) até que alguém possa tentar recuperar arquivos.

• cp new_file old_file fará o seguinte (você pode usar strace para ver as chamadas do sistema):

  open("old_file", O_WRONLY|O_TRUNC) = 4

  O sinalizador O_TRUNC fará com que todos os blocos de dados sejam liberados, assim como mv fez acima. E como acima, eles geralmente serão adicionados a uma lista livre e podem ou não ser reutilizados pelas gravações subseqüentes feitas pelo comando cp .

• vi existing_file . Se vi for realmente vim , o comando :x fará o seguinte:

  unlink("existing_file~") = -1 ENOENT (No such file or directory)

  rename("existing_file", "existing_file~") = 0

  open("existing_file", O_WRONLY|O_CREAT|O_TRUNC, 0664) = 3

  Por isso, nem remove os dados antigos; os dados são preservados em um arquivo de backup.

  No FreeBSD, vi faz open("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664) , que terá a mesma semântica de cp , acima.

Você pode recuperar alguns ou todos os dados sem programas especiais; tudo o que você precisa é de grep e dd e acesso ao dispositivo bruto.

Para pequenos arquivos de texto, o único comando grep na resposta de @Steven D na pergunta você vinculou é a maneira mais fácil:

grep -i -a -B100 -A100 'text in the deleted file' /dev/sda1

Mas, para arquivos maiores que podem estar em vários blocos não contíguos, eu faço isso:

grep -a -b "text in the deleted file" /dev/sda1
13813610612:this is some text in the deleted file

que lhe dará o deslocamento em bytes da linha correspondente. Siga isso com uma série de comandos dd , começando com

dd if=/dev/sda1 count=1 skip=$(expr 13813610612 / 512)

Você também gostaria de ler alguns blocos antes e depois desse bloco. No UFS, os blocos de arquivos são geralmente de 8 KB e são geralmente alocados de forma razoavelmente contígua, blocos de um único arquivo sendo intercalados alternadamente com blocos de 8 KB de outros arquivos ou espaço livre. A cauda de um arquivo no UFS é de até 7 fragmentos de 1 KB, que podem ou não ser contíguos.

Naturalmente, em sistemas de arquivos que compactam ou criptografam dados, a recuperação pode não ser tão simples.

Na verdade, existem muito poucos utilitários no Unix que sobrescrevem os blocos de dados de um arquivo existente. Um que vem à mente é dd conv=notrunc . Outro é shred .

    

Answer 2

Eu vou dizer não (com um asterisco gigante).

Pense em como os dados são colocados em um disco. Você tem blocos que contêm dados e apontam para o próximo bloco (se houver um).

Quando você sobregrava os dados, você está alterando o conteúdo do bloco (e se você está estendendo o arquivo todo o marcador final). Então nada deve poder ser recuperado (veja abaixo).

Se você encurtar o arquivo, estará perdendo os blocos antigos e eles serão reciclados em breve. Se você é um programador, pense em uma lista vinculada na qual você "perde" metade da sua lista sem fazer um free / delete. Esses dados ainda estão lá, mas boa sorte para encontrá-lo.

Algo que pode ser interessante pensar é a fragmentação.

A fragmentação ocorre quando há "buracos" de dados não contíguos no disco. Isso pode ser causado pela modificação de arquivos que os estendem ou encurtam e não se encaixam mais no local original do disco.

No caso de um arquivo ultrapassar seu tamanho original (ele precisa ser movido neste ponto), dependendo do sistema de arquivos, você pode copiar o arquivo inteiro para um novo local onde os dados antigos ainda estarão lá (mas marcados como livre) ou apenas altere o ponteiro final antigo e aponte para um novo local (isso levará a uma surra).

Para encurtar a história, seus dados provavelmente estão perdidos (sem passar por um processo forense extremo, onde você o observa sob um microscópio); no entanto, há uma chance de que ainda esteja lá.

    

Answer 3

Certifique-se de ter espaço suficiente em disco em / var / tmp ou em algum lugar grande.

Tente

 grep -i -a -B100 -A100 'a string unique to your file' /dev/sda1 |
 strings > /var/tmp/my-recovered-file

onde / dev / sda1 seria o seu disco no seu sistema.

Em seguida, pesquise my-recover-file por sua string.

pode estar na maioria das vezes, se você encontrar, verifique se faltam espaços de linha, colchetes, sysmbols etc.

Use uma palavra de busca do seu arquivo que seja bastante unqiue ou string que reduza a quantidade de dados no arquivo. Se você procurar por uma palavra como "echo", você receberá de volta cargas de strings, pois o sistema terá muitos arquivos com a palavra echo neles.

    

Answer 4

Eu havia sobrescrito um arquivo de texto (VQ1.txt) com 12 horas de dados de teste: Uma noção de que o unix salva a versão anterior do arquivo no formato text.txt ~, me fez olhar para pasta contendo o arquivo sobrescrito com $ -ll A lista completa mostrava VQ1.txt ~ que tinha meus dados 'perdidos'!

$ cat VQ1.txt~  
Start time at: Thu Apr  2 18:07:23 PDT 2015
User, KW: 12hrFA_OEM_HelloVoiceQ
Test Case: 
Detection:  1, 1, 04-03 01:07:00.673 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  2, 1, 04-03 01:09:04.813 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  3, 1, 04-03 04:09:26.023 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  4, 1, 04-03 04:11:29.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  5, 1, 04-03 07:12:27.013 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  6, 1, 04-03 07:14:30.803 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  7, 1, 04-03 08:37:13.113 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  8, 1, 04-03 10:21:23.533 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  9, 1, 04-03 10:23:27.733 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  10, 1, 04-03 13:23:47.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  11, 1, 04-03 13:25:52.203 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1

12hrFA_OEM_HelloVoiceQ,  
KW detect count: 11