ext4 filesystem remanescentes salvos com testdisk

Question

Chegando ao ponto: testdisk é capaz de navegar pelo sistema de arquivos e hierarquia (aparentemente como se estivesse intacto) e individualmente recuperar arquivos. Existe uma maneira de fazer isso automaticamente?

A história:

Estou trabalhando em um clone dd de um clone gddrescue imutável (cópia setor a setor) de um disco externo USB de 3 TB usado em uma rPI de 2016 até outubro de 2017. Acredito que ele continha 2 partições: 6GB e ~ 3TB (??) Os 6GB foram recuperados e montados. Na clonagem, o ddrescue não conseguiu copiar ~ 1MB (total) em 25 áreas da unidade.

Meu objetivo é salvar o máximo possível de organização, arquivos e horários de modificação de arquivos grandes. O primeiro tem sido usado, mas perde a organização (a maior parte do valor).

Agora estou trabalhando com o Ubuntu 16.04.03LTS, a tabela de partições imutáveis do clone tem os limites errados e usei o testdisk para escrever um plausível para a unidade de recuperação - e recuperei o sistema de arquivos da primeira partição pequena. Curiosamente, o fdisk reporta o tipo drivelabel como DOS e menciona um limite (2 ^ 32 setores?), E a partição grande escrita pelo testdisk é mostrada como apenas 2TB. Com parted, eu mudei para GPT e agora é o full ~ 3TB como ~ 5.86Gsectors.

O segundo sistema de arquivos de partição é navegável com o testdesk, e eu posso salvar arquivos individualmente. Mas é provável que haja mais de um milhão.

A pergunta: Isso me diz que algum do sistema de arquivos está presente e parcialmente intacto - mas eu não sei como usar o testdisk para automaticamente capturar a estrutura de arquivos e arquivos que estão presentes.

O testdisk pode fazer isso? Ou existe outra ferramenta que pode fazer uso do que é bom no sistema de arquivos? Possivelmente, adicionar código ao testdisk para realizar isso automaticamente é uma abordagem razoável?

Outra abordagem: Depois de 'consertar' a tabela de partição com o testdisk, o e2fsck na partição 2 (~ 3TB) reporta:

"" O tamanho do sistema de arquivos (de acordo com o superbloco) é de 730993525 blocos O tamanho físico do dispositivo é 536870911 blocos O superbloco ou a tabela de partições provavelmente estará corrompida! ""

Executar mke2fs -S seguido por e2fsck resulta em erros em todos os lugares e não deixa nada de valor.

É provável que em outubro de 2017, o mke2fs -S tenha sido executado na segunda partição, mas usando a tabela de partição original corrompida.

Uma terceira abordagem: Testdisk é um pouco opaco para mim, então eu escrevi um programa para encontrar superblocos, e verifiquei seu último ponto de montagem, etc. Assim, estou confiante de que a unidade contém superblocos intactos da grande partição. Se eu tenho um desses superblocos, eu poderia fazer uso de alguma forma de tal forma que e2fsck poderia fazer o resto? Imagino que o superbloco, no entanto, só teria endereço de bloco em relação ao início da partição. Como o superbloco tinha que estar em um dos vários locais (e tem um padrão de salto conhecido), talvez eu pudesse usar essa informação para atribuir o início correto da localização da partição?

TIA!

    

Answer 1

Você está procurando e2fsck com os superblocos descobertos pelo testdisk? Em >[ Advanced ] Filesystem Utils , o comando >[Superblock] deve "Localizar superbloco de backup ext2 / ext3 / ext4" semelhante a este:

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org

Disk 1 - 104 MB / 100 MiB - CHS 13 255 63

     Partition                  Start        End    Size in sectors

  ext2                     0   0  1    12 190 50     204800
superblock 0, blocksize=1024 []
superblock 8193, blocksize=1024 []
superblock 24577, blocksize=1024 []
superblock 40961, blocksize=1024 []
superblock 57345, blocksize=1024 []
superblock 73729, blocksize=1024 []

To repair the filesystem using alternate superblock, run
fsck.ext2 -p -b superblock -B blocksize device


>[  Quit  ]
                            Return to Advanced menu

E tente o comando fsck.ext2 / e2fsck sugerido com superblocos diferentes até encontrar um "bom".

Além disso, o Testdisk parece capaz de copiar pastas inteiras, portanto, se grande parte do sistema de arquivos ainda estiver lá, pode ser apenas as pastas na raiz que precisam de cópia manual e todas as suas subpastas & os arquivos serão copiados também.

Espero que haja apenas alguns no root, e não milhões, embora o : para selecionar arquivos para cópia posterior seja movido para o próximo arquivo, e a selecione todos os arquivos (nessa pasta)

Aqui está uma "captura de tela" logo após copiar a pasta "Downloads" do root (ela contém 2 arquivos, e a mensagem Copy done! 2 ok, 0 failed está em verde):

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
   P ext2                     0   0  1    12 190 50     204800
Directory /
Copy done! 2 ok, 0 failed
 drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 .
 drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 ..
 drwx------     0     0     12288 17-Jan-2018 07:49 lost+found
 drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 Documents
>drwxr-xr-x     0     0      1024 17-Jan-2018 07:50 Downloads



                                                   Next
Use Right to change directory, h to hide deleted files
    q to quit, : to select the current file, a to select all files
    C to copy the selected files, c to copy the current file