Comando dd errado na unidade principal - Como recuperar dados?

Question 1

Presumo que a tabela de partições e a partição de inicialização possam ser recriadas facilmente, então vou me concentrar na partição ext4.

O layout do sistema de arquivos depende um pouco das opções usadas ao criá-lo. Descreverei o caso comum. Você pode ver se isso corresponde ao seu executando dumpe2fsno dispositivo (que provavelmente encontrará todos os metadados de nível superior no cache, em vez de ler no disco).

O tamanho normal do bloco para sistemas de arquivos ext4 é 4.096 bytes, então você perdeu 1.024 blocos.

A primeira coisa substituída foi o bloco 0, o superbloco primário. Isso não é um problema por si só, porque existem superblocos de backup. Depois disso está a tabela de descritores de grupo, que também possui backups dentro do sistema de arquivos.

Depois, há bitmaps de bloco e bitmaps de inode. É aqui que as notícias começam a piorar um pouco. Se algum deles estiver abaixo do bloco 1024, o que provavelmente está, você perdeu informações sobre quais inodes e blocos estão em uso. Esta informação é redundante e será reconstruída pelo fsck com base no que encontrar percorrendo todos os diretórios e inodes, se estes estiverem intactos.

Mas a próxima coisa é a tabela de inodes, e aqui você provavelmente perdeu muitos inodes, incluindo o diretório raiz, diário e outros inodes especiais. Será bom tê-los de volta. Obviamente, pelo menos o diretório raiz ainda está funcional, ou quase todos os comandos que você tenta executar já estariam falhando.

Se você executar um dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024agora, obterá uma cópia de backup de tudo o que está em seu cache atualmente, misturado com os dados inválidos dos blocos que não estão armazenados em cache. Então, depois de inicializar um disco de recuperação, você pode fazer o mesmo ddao contrário, para colocar os dados parcialmente bons de volta no disco, substituindo as coisas ruins que estão lá agora.

Depois disso, você poderá descobrir que as ferramentas de recuperação automatizadas ( fsck, testdisk) funcionam bem o suficiente. Caso contrário, você tem um mapa que pode usar para ajudar na recuperação manual. Usando as listas de "blocos livres" do dumpe2fs, você sabe quais blocos ignorar.

A maior parte do que você perdeu provavelmente são inodes. Na verdade, é bastante provável que você não tivesse nenhum arquivoconteúdonos primeiros 4 MB do disco. (Executei mkfs.ext4sem opções em um arquivo de imagem de 1 TB, e o primeiro bloco não-metdata acabou sendo o bloco 9249)

Cada inode que você conseguir recuperar identificará os blocos de dados de um arquivo inteiro. E esses blocos de dados podem estar localizados em todo o disco, não necessariamente nas proximidades.

Dia 2

O dump postado no pastebin revela ótimas notícias:

Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
  Primary superblock at 0, Group descriptors at 1-117
  Reserved GDT blocks at 118-1141
  Block bitmap at 1142 (+1142)
  Inode bitmap at 1158 (+1158)
  Inode table at 1174-1685 (+1174)
  21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
  Free blocks: 11419-32767
  Free inodes: 16-8192

Como acreditamos que apenas 4 MB no início do sistema de arquivos foram sobrescritos, só precisamos nos preocupar com os blocos 0-1023. E os blocos GDT reservados vão até o bloco 1141! Este é o tipo de dano que deve ser reparado de forma simples e2fsck -b $backup_superblock_number(após uma reinicialização). Você poderia pelo menos tentar isso para -nver o que ele pensa.

Answer