Como posso descobrir quais arquivos são perdidos em uma tentativa de recuperação do ddrescue?

Question

Estou no processo de recuperar dados de uma unidade com falha de 1 TB (perguntei sobre isso em Procedimento para substituir um disco rígido? ). Eu fiz ddrescue de um sistema de resgate USB com um tamanho de erro resultante de 557568 B em 191 erros, provavelmente todos em /home (eu assumo o que ele chama de "erros" não são setores defeituosos, mas sequências consecutivas deles).

Agora, os vários guias que eu vi sugerem e2fsck no novo disco, e eu esperava que isso de alguma forma achasse que alguns arquivos foram atribuídos a "setores / blocos em branco", para o efeito de pelo menos saber quais arquivos não podem ser salvos por inteiro. Mas nenhum erro foi encontrado (eu corri sem -y para ter certeza que eu não perdi nada). Agora estou rodando novamente com -c , mas a 95% nenhum erro foi encontrado até agora; Eu acho que tenho uma nova unidade com alguns arquivos de aparência normal com peças zeradas ou aleatórias dentro, indetectáveis até que no dia em que eu abri-los com o software correspondente, ou o Linux Mint precisa deles.

Posso fazer algo com as unidades antigas / novas para obter uma lista de arquivos possivelmente corrompidos? Não sei quantos poderiam ser, já que os 191 poderiam passar por arquivos, mas pelo menos o tamanho total não é grande; Eu estou principalmente preocupado com um monte de fotos e vídeos antigos da família (1+ MB cada), o resto é provavelmente irrelevante ou foi feito um backup recentemente.

Atualização: o novo passe do e2fsck deu algo novo, que eu não entendo nada:

Block bitmap differences:  [phone] +(231216964--231216965) [phone] [phone] [phone] +(231217870--231217871) [phone]
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).                    
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes

    

Answer 1

Você precisará dos números de bloco de todos os blocos danificados encontrados ( ddrescue deveria ter lhe dado uma lista, espero que tenha sido salvo), e então você precisará descobrir quais arquivos fazem uso desses blocos ( veja, por exemplo, aqui ). Você pode querer fazer o script se houver muitos blocos ruins.

e2fsck não ajuda, apenas verifica a consistência do sistema de arquivos em si, portanto, apenas os blocos ruins conterão informações do sistema de arquivos "administrativo".

Os blocos defeituosos nos arquivos estarão vazios.

Editar

Ok, vamos descobrir o tamanho do bloco. Vamos fazer um sistema de arquivos de teste com blocos de dispositivos de 512 bytes:

$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs

$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs

$ /sbin/tune2fs -l fs
...
Block count:              100
...
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192

Portanto, o tamanho do bloco do sistema de arquivos é 1024, e temos 100 desses blocos do sistema de arquivos (e 200 blocos de dispositivos de 512 bytes). Resgate:

$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:    102400 B,  errsize:       0 B,  current rate:     102 kB/s
   ipos:     65536 B,   errors:       0,    average rate:     102 kB/s
   opos:     65536 B, run time:       1 s,  successful read:       0 s ago
Finished                                     

$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time:   2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos  current_status
0x00010000     +
#      pos        size  status
0x00000000  0x00019000  +

$ printf "%i\n" 0x00019000
102400

Portanto, as unidades hex ddrescue estão em bytes, não em blocos. Finalmente, vamos ver o que o debugfs usa. Primeiro, crie um arquivo e encontre seu conteúdo:

$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp

$ hexdump -C fs
...
00005400  61 62 63 64 65 66 67 68  69 6a 6b 0a 00 00 00 00  |abcdefghijk.....|
00005410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Portanto, o endereço de bytes dos dados é 0x5400 . Converta isso em blocos do sistema de arquivos de 1024 bytes:

$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21

e vamos também tentar o intervalo de blocos enquanto estamos nisso:

$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs:  testb 0
testb: Invalid block number 0
debugfs:  testb 1
Block 1 marked in use
debugfs:  testb 99
Block 99 not in use
debugfs:  testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs:  testb 21
Block 21 marked in use
debugfs:  icheck 21
Block   Inode number
21      12
debugfs:  ncheck 12
Inode   Pathname
12      //foo

Isso funciona como esperado, exceto que o bloco 0 é inválido, provavelmente porque os metadados do sistema de arquivos estão lá. Assim, para o seu endereço de byte 0x30F8A71000 de ddrescue , supondo que você trabalhou em todo o disco e não em uma partição, subtraímos o endereço de byte do início da partição

210330128384 - 7815168 * 512 = 206328762368

Divida isso pelo tamanho do bloco tune2fs para obter o bloco do sistema de arquivos (observe que, como vários blocos físicos, possivelmente danificados, formam um bloco do sistema de arquivos, os números não precisam ser múltiplos exatos):

206328762368 / 4096 = 50373233.0

e esse é o bloco que você deve testar com debugfs .