Estou no processo de recuperação de dados de uma unidade com falha de 1 TB (perguntado sobre isso emProcedimento para substituir um disco rígido?). Eu fiz ddrescuea partir de um USB de resgate do sistema com um tamanho de erro resultante de 557568 B em 191 erros, provavelmente todos incluídos /home(presumo que o que ele chama de "erros" não sejam setores defeituosos, mas sequências consecutivas deles).
Agora, os vários guias que vi por aí sugerem fazer isso e2fsckno novo disco, e eu esperava que isso de alguma forma descobrisse que alguns arquivos foram atribuídos a "setores/blocos em branco", no sentido de pelo menos saber quais arquivos não puderam ser salvos todo. Mas nenhum erro foi encontrado (eu executei sem -yter certeza de que não perdi nada). Agora estou executando novamente com -c, mas em 95% nenhum erro foi encontrado até agora; Acho que tenho uma nova unidade com alguns arquivos de aparência normal com partes zeradas ou aleatórias dentro, indetectáveis até o dia em que eu os abro com o software correspondente, ou o Linux Mint precisa deles.
Posso fazer alguma coisa com as unidades antigas/novas para obter uma lista de arquivos possivelmente corrompidos? Não sei quantos poderiam ser, já que 191 poderiam passar por arquivos, mas pelo menos o tamanho total não é grande; Estou mais preocupado com um grande número de fotos e vídeos antigos de família (mais de 1 MB cada), o resto provavelmente é irrelevante ou foi copiado recentemente.
Atualização: a nova passagem do e2fsck deu algo novo do qual não entendo nada:
Block bitmap differences: +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
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
Responder1
Você precisará dos números dos blocos de todos os blocos defeituosos encontrados ( ddrescuedeveria ter fornecido uma lista, espero que você a tenha salvo) e então precisará descobrir quais arquivos fazem uso desses blocos (veja, por exemploaqui). Você pode querer criar um script se houver muitos blocos defeituosos.
e2fscknão ajuda, apenas verifica a consistência do próprio sistema de arquivos, portanto, agirá apenas se os blocos defeituosos contêm informações "administrativas" do sistema de arquivos.
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 é 1.024 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 hexadecimais ddrescueestão em bytes, e não em blocos. Finalmente, vamos ver o que debugfsusa. 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 de 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
Então isso funciona conforme o esperado, exceto que o bloco 0 é inválido, provavelmente porque os metadados do sistema de arquivos estão lá. Portanto, para o seu endereço de byte 0x30F8A71000de 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 tune2fstamanho do bloco para obter o bloco do sistema de arquivos (observe que, como vários blocos físicos, possivelmente danificados, constituem um bloco do sistema de arquivos, os números não precisam ser múltiplos exatos):
206328762368/4096 = 50373233,0
e esse é o bloco com o qual você deve testar debugfs.
Responder2
NTFS, ext3, ext4
Depois de copiar os dados de sua unidade com falha com ddrescue, useddrutilitypara encontrar os nomes dos arquivos afetados.
Consegui listar os arquivos NTFS afetados em uma partição de 1 TB com um ddrescuearquivo de mapa em menos de 20 segundos.
Ele grava seu arquivo de log no diretório atual.
A página vinculada menciona suporte para NTFS, ext3 e ext4.
btrfs, zfs
Esses sistemas de arquivos têm sua própria função integrada scrub.
Responder3
Eu recomendaria um utilitário já implementado chamado ddrutility. Isso eliminaria os tediosos cálculos manuais.
Você deveria executá-lo em seu clonadocópia de(não o original) dispositivo de unidade assim:
ddru_findbad /dev/sdb /ddrescue-disk-copy.map
O uso do arquivo map (segundo argumento) é obrigatório aqui.
O utilitário é bastante inteligente, suporta diferentes sistemas de arquivos (até mesmo NTFS) e também possui a funcionalidade de testar setores errados que ainda serão divididos (marcando-os como temporários defeituosos), portanto, você poderá estimar se precisa de todo o ddrescueprocedimento terminar. Observe também que isso /dev/sdbé usado como um disco inteiro aqui (não como uma partição como /dev/sdb1), já que todo o disco foi originalmente clonado.
O utilitário está disponível nos repositórios Debian e pode ser instalado com:
sudo apt install ddrutility
Wiki do projeto:https://sourceforge.net/p/ddrutility/wiki/Home
Responder4
Usei o Filezilla simples e resolvi meu problema. Use o Filezilla normal para fazer backup de todos os dados válidos. Percebo que um arquivo grande não estava sendo copiado corretamente (parando no meio e reiniciando a transferência). Felizmente tenho um backup anterior do mesmo arquivo. Para duplicar o disco, tive que encontrar os blocos defeituosos no disco usando este procedimento:
Primeiro descubra o disco com problema identificando as informações do HD usandofdisk -l
2º se digamos que seu disco está/dev/sdbentão você precisa executar o comando badblocks -v /dev/sdbele listará todos os seus blocos defeituosos na unidade. Felizmente, haverá alguns. Se nenhum bloco defeituoso for encontrado, então seus blocos de unidade estão OK e precisam descobrir outra coisa. O tamanho do meu bloco é 512, então uso esse número padrão para executar o DD
Terceiro, cada bloco tem tamanho 512, então o que fiz foi definir bs = 512
Cada vez que executei o DD regularmente, como sempre faço, meus dados, após os erros, ficarão corrompidos. Então eu uso os parâmetros conforme explicado na páginahttps://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.htmlpesquise a parte "Para discos com falha".
dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock
Demorou um pouco. Cada bloco defeituoso encontrado soa como uma batida na unidade defeituosa. Ele copia bloco por bloco e, através de todos os meus blocos defeituosos, faz o mesmo barulho. A quantidade de vezes que fez barulho foi porque encontrou outro bloco defeituoso e informa sobre a mensagem de erro no display. O que'conv=noerror,sincronização'faz, é preencher leituras ruins com NULs, enquanto'iflag=bloco completo'atende leituras curtas, mas mantém sincronizados seus dados até o final. Nenhuma corrupção, apenas não copia os blocos defeituosos e os preenche com NULs vazios.
Depois que a cópia com DD foi feita, eu apenas substituí aquele arquivo ruim, revertendo o Filezilla de um backup anterior e tudo funcionou bem. Espero que isso seja útil para outras pessoas que tentam fazer backup de unidades defeituosas.
NOTA: Meus blocos ruins estavam bem próximos um do outro. Cerca de 4 blocos por vez juntos em grupos onde foram detectados erros. Se os seus blocos estiverem espalhados por todo o disco, vários arquivos poderão ser afetados. Felizmente, no meu caso, um grande arquivo de banco de dados de 4GB só foi afetado.