recuperando a partição ext4 após o dd'ing sobre o início do HD

Question

Eu acidentalmente usei dd e escrevi os primeiros 208MB do meu disco externo. O que eu escrevi é uma partição própria (nestinstaller do Debian), então o que eu vejo agora não é minha partição ext4 antiga (agora danificada), mas outra partição menor. Isso limita as ferramentas e conselhos que eu poderia seguir.

Meu plano era recriar a tabela de partições com testdisk e depois consertar tudo com os superblocos de backup como descrito aqui . Eu perderia os primeiros 208MB, mas tudo bem comparado aos outros 300GB de dados lá. Algo como o seguinte:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

No entanto, não consegui recuperar nada. Eu usei testdisk para escrever uma nova tabela de partição que correspondia ao que eu tinha antes. Quando eu executo o e2fsck, recebo muitos erros diferentes. Eu recebo um sistema de arquivos depois disso, mas está completamente vazio, sem arquivos.

O diretório lost + found está cheio de arquivos (os recuperados eu acho), mas eu preciso recuperar a árvore de diretórios, não apenas os arquivos. Eu preciso do nome do arquivo e diretórios anteriores para saber quais são os arquivos (imagens de microscópio, dados de especificação de massa, etc. Sem os nomes e os diretórios onde estavam, eles não significam nada).

Eu consegui outro HD exatamente igual e fiz uma cópia do HD inteiro com dd para que eu possa experimentar a recuperação sem perder nada. Algum conselho?

    

Answer 1

Eu finalmente consegui consertar isso. Apenas para o registro aqui é como eu fiz isso. Parte da solução que encontrei aqui e envolve conhecer as configurações usadas para criar o sistema de arquivos (eu tinha certeza que não alterei os padrões).

Basicamente eu primeiro tive que consertar a tabela de partições para refletir o que eu tinha lá (eu usei testdisk para isso, mas parted , cfdisk ou fdisk deveria funcionar bem também). Acabei de remover as partições erradas e substituí-las por uma única partição do tipo ext4 cobrindo todo o disco com os valores de CHS corretos.

O restante é principalmente do link no início (leia para detalhes), mas basicamente eu corri mke2fs -n /dev/xxx para encontrar as posições para o backup de superblocos. Em seguida, usei o último backup mais próximo do final do disco (somente aqueles no início do disco foram substituídos pelo dd) para executar o fsck. Isso gerou muitos erros, mas o fsck tem uma opção -y (não o mesmo que -a ).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

Eu achei que isso não funcionou porque não consegui ver nenhum arquivo, mas na verdade eles foram salvos no diretório lost+found .

Então, no final, salvei a maioria dos meus arquivos, mantendo seus nomes de arquivos e estrutura de diretórios. Espero que isso possa ajudar os outros no futuro.

    

Answer 2

Ok, isso funciona para recuperar de uma unidade acidentalmente inita em um array MegaRAID. Meu controlador RAID ini- ciou TODAS as unidades no RAID, não apenas as do RAID6 que eu estava refazendo. Ai! Pelo menos eu fiz um init rápido, e não um init lento - o init lento limpa a unidade para zeros.

O Quick init apaga 10 M no início e no final das unidades. Então, eu com uma partição ext4 em toda a unidade (no Linux) e uma unidade, RAID0, tive alguma chance. Com a unidade sendo uma unidade de 6 TB, e quase 5 TB, eu estava suando - era meu backup da matriz RAID6 que eu estava reformando!

A propósito, eu não escorreguei - o LSI MegaRAID NÃO deveria ter unidades inatas no meu outro grupo de drive - mas funcionou. Como uma nota, o que eu deveria ter feito é remover esse drive do gabinete e reimportá-lo DEPOIS de ter o grupo de drives RAID6 recém-arranjado. Me bobo. REALMENTE bobo me ....

OK, felizmente o LSI MegaRaid não gosta de nada com drives RAID0 (se houver um que eu não tenha certeza sobre múltiplos). Aqui está o que eu fiz para consertar isso. OS = Fedora F22. Drive = uma grande partição ext4, feita com parted. Primeiro gravei a unidade para uma unidade de novo modelo, exatamente igual, em um servidor sobressalente com alguns compartimentos de compartimento sobressalentes: Dez horas depois ela terminou ......

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

Esse foi o meu backup de ouro.

OBSERVAÇÃO - Minha unidade era /dev/sdb - você precisa definir sua unidade para qualquer unidade que esteja tentando recuperar. Não estrague as unidades, ou você estará ainda mais confuso ...

Depois disso, fiz o seguinte.

(1) remover instantâneo da máquina (não bobo novamente, posso assegurar-lhe - que um seria desligado para recuperação de disco hospital se eu falhei, enquanto eu me registrei no ER local!)

(2) reinicialize a máquina FC22 com a unidade. Execute o parted, refaça a partição (no meu caso, exclua o corrompido, escreva em uma nova partição ext4 de 0% a 100%). Você tem que saber exatamente onde as partições originais estavam, e seu tipo exato - o próximo passo depende disso - se não, PARE AQUI. Você não vai conseguir. use testdisk e photorec ou similar, ou para uma grande unidade onde realmente importa, envie-a para fora.

(3) execute mke2fs -n /dev/sdb1 (não se esqueça do -n , ou novamente você pode simplesmente ir embora ...)

Para mim, o resultado parecia:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Aí está você, é onde todas as super peças sobressalentes são ...... Sabemos que o primeiro e o último são lixo, mas os que estão no meio devem estar bem. (Note que você pode usar mkfs.ext4 -n /dev/sdb1 para ser super cauteloso e obter o mesmo resultado).

(4) Execute e2fsck -y -b 102400000 /dev/sdb1 . Você precisará do -y , pois haverá um monte de "sim" necessários para consertar a bagunça criada pelo front end ausente do disco .... e escolher qualquer superbloco no meio que você gosta ... e depois cerca de 30 minutos de silêncio (use outro terminal e "top" para assistir ao progresso, ou a luz do disco piscando) no meu caso pronto, uma partição montável e praticamente tudo intacto no diretório /lost+found .

De qualquer forma, espero que isso ajude - se você está lendo isso com cuidado, então desejo-lhe boa sorte. E obrigado aos caras escrevendo acima. Você me salvou de um final muito doentio .....