Recuperando o sistema de arquivos na partição desconfigurada

2

Acionei acidentalmente a partição do Acer Recovery do meu laptop multi-boot e, apesar de selecionar EXIT quando tive a chance de recuperar alguma coisa ou não, uma das minhas partições foi destroçada. Agora eu poderia realmente usar alguns conselhos sobre como reescrever a tabela de partições e recuperar o sistema de arquivos.

  1. Eu clonei a unidade inteira (dd se = ... | ssh me @ desktop -of = ...) e estou trabalhando exclusivamente na unidade clonada.

  2. Eu tentei o gpart, parted, testdisk (assim como o gparted). Sem sorte até agora.

Meu layout de unidade é:

/dev/sda1 ntfs 12GB
/dev/sda2 ntfs 100MB
/dev/sda3 ntfs 72.17GB
/dev/sda4 extended 213.82GB
  unallocated 27.93GB
  /dev/sda5 ext4 148.98GB
  /dev/sda6 ext4 29.33GB
  /dev/sda7 swap 7.58GB
unallocated 2.49MB

A partição desconfigurada é a partição não alocada de 30 GB (primeira partição lógica na partição estendida).

Pena que o Acer Recovery atingiu essa partição exata. Eu não teria me preocupado em tentar recuperar qualquer um dos outros (Windows que eu não uso, Linux para testes, Linux alt. Distro também para testes). Este, no entanto, contém dados que eu realmente gostaria de recuperar.

Eu sei os limites exatos da partição, eu sei os detalhes do sistema de arquivos subjacente (ext4).

No entanto, as ferramentas geralmente recomendadas para recuperar não estão funcionando. Uma verificação profunda pelo testdisk indicou que a ferramenta Acer Recovery aparentemente decidiu copiar a tabela de partição para a partição principal do Windows, resultando em reclamações sobre os tamanhos não correspondentes. gpart, parted e testdisk não conseguiram encontrar um sistema de arquivos. O testdisk encontrou um sistema de arquivos NTFS que era "irrecuperável".

Eu suspeito que o superbloco também foi ativado, mas uma pesquisa revelou a existência de vários superblocos de backup.

Qual é a melhor aposta para avançar? Eu quero tentar reescrever a tabela de partição e recuperar o sistema de arquivos, presumivelmente com o e2fsck usando um superbloco de backup.

Qual ferramenta me permitirá reescrever a tabela de partições sem fazer nada aos meus dados? Que tal configurar um sistema de arquivos? Eu precisaria fazer isso antes de tentar restaurar o superbloco do backup? Como?

TIA,

fyo

    
por fyo 18.06.2015 / 00:20

3 respostas

0

Se você está perguntando se você pode recuperar a partição não alocada de 30GB, eu não acho que você pode. Partições não alocadas não podem ser recuperadas do meu entendimento. Alguém me corrija se eu estiver errado.

    
por 18.06.2015 / 00:27
0

Desde que você declara que conhece os limites da partição, eu usaria o losetup com as opções -o offset e --sizelimit size

Isso permitirá que você crie um dispositivo de loopback da partição de 30 GB em que você pode operar. Se a partição não for sobrescrita, uma pesquisa no Testdisk do dispositivo de loopback deverá encontrar algo.

Você também pode usar o Photorec para pesquisar arquivos com base na extensão de arquivo, se apenas para verificar se seus dados ainda estão lá.

    
por 26.06.2015 / 22:01
0

Finalmente resolvido e tudo voltou ao normal. Havia algumas esquisitices que outros poderiam aprender, então aqui estão os detalhes:

Tudo foi feito em um CLONE da minha unidade. Por favor, clone sua unidade (ou pelo menos partição) antes de começar a brincar com qualquer coisa, de preferência de um CD ao vivo.

Meu primeiro passo depois que as ferramentas usuais falharam em produzir um resultado (de acordo com o OP) foi simplesmente usar um editor hexadecimal ( hexedit ) para editar a partição inteira, pulando para o primeiro byte de o espaço não alocado onde minhas coisas deveriam estar.

Compare os resultados no editor hexadecimal com Layout de Disco Ext4: link

Tudo estava bem claro lá. O superbloco, que todas as ferramentas relataram era ruim, estava lá e parecia perfeitamente bem. Os dados estavam lá. Provavelmente, a única coisa que todo mundo sofreu foi a tabela de partições.

No entanto, , o superbloco foi deslocado 2048 bytes em oposição a 1024 bytes por especificação. Aparentemente, isso causou a falha de muitas das ferramentas.

Munido desse conhecimento, lancei novamente o testdisk e comecei a traduzir seus trios CHS para setores para ver o que diabos estava acontecendo. Como mencionado inicialmente, o testdisk encontrou realmente o que era presumivelmente minha partição, mas não a restauraria. Depois de verificar os limites setoriais de todas as partições, o motivo ficou claro:

O Testdisk mostrou que minhas partições eram maiores do que de fato eram (sda3 e sda5 no OP). Não sei porquê. A tabela de partições atual mostrava o tamanho correto e o sistema de arquivos ext4 em sda5 mostrava o número correto de blocos. No caso de sda5, o testdisk encontrou a partição para sobrepor o sda6, portanto, não permitiria que eu selecionasse ambos na lista de partições revisada. No caso de sda3, as partições não se sobrepunham, mas o testdisk ainda não me permitia restaurar minha partição ausente junto com sda3. O intervalo entre eles era presumivelmente menor do que o do testdisk, por qualquer motivo.

A criação de uma partição com o GParted no espaço não alocado não funcionava porque o GParted insistia em um intervalo de 1 MB entre o sda3 e a nova partição. Mesmo com o tamanho sda3 correto, isso resultaria no superbloco (e muito mais) sendo apagado, de modo que foi um não-ir. Um pouco estranho, já que todas as minhas partições (exceto as duas do Windows Restore) foram criadas com várias versões do GParted.

A solução era usar o parted em vez disso e inserir manualmente os limites corretos, que foram detectados corretamente pelo testdisk (e verificado com o hexedit, já que o testdisk não detectou com precisão outros limites).

Ufa.

    
por 30.06.2015 / 23:42