Tenho uma coleção de disquetes antigos de 3,5 "dos quais pretendo recuperar o máximo de dados possível.
O problema é devido à estrutura de alguns dos arquivos, preciso que o comprimento de todos os arquivos seja mantido, o que significa que quaisquer setores defeituosos devem ser preenchidos (a razão tl; dr porque alguns arquivos são arquivos Acorn ADFS onde os dados e o código são combinado. O código faz referência aos dados como um deslocamento desde o início do arquivo. A leitura do formato ADFS não é um problema no Linux, o preenchimento de setores defeituosos é).
Os discos não são lidos há 25 anos, então espero leituras imprevisíveis, setores defeituosos regulares e potencialmente tornar os discos ilegíveis - o que não me importa, desde que a recuperação de dados seja maximizada.
Para fazer isso, espero que sejam necessárias várias passagens para ler o máximo possível.
dd
Eu olhei para dd, com este comando prometendo uma primeira execução:
dd if=/dev/fd0 of=adfs.img conv=noerror,sync
Seguido por chamadas subsequentes de
dd if=/dev/fd0 of=adfs.img conv=noerror,notrunc
Onde:
sem errosignifica que os erros são ignorados
sincronizarsignifica que setores defeituosos são preenchidos com o caractere nulo
não truncadosignifica que o arquivo de saída (já existente) não é truncado quando dd é chamado.
Contudo, ao ler opágina de manuale istoexplicação de notrunc, apesar de notrunc estar definido, dd substitui a saída todas as vezes, resultando em uma saída que ainda representa apenas o que foi lido na última passagem. Quaisquer setores anteriormente lidos corretamente, mas agora ruins, por exemplo, devido à degradação de um disquete antigo, serão substituídos por nulos.
Então dd não parece adequado.
ddrescue
ddrescueparece promissor porque pode ser usado com múltiplas passagens, desde que um arquivo de log seja usado para registrar o que foi escrito com sucesso e então referido quando a próxima passagem for concluída.
A primeira passagem para ler apenas blocos sem erro
ddrescue -d -p --no-scrape /dev/fd0 output.img log/output.logfile
para a primeira passagem e passagens subsequentes para preencher os erros
ddrescue -d -r3 /dev/fd0 output.img log/output.logfile
Onde
-dacesso direto ao disco. Ignorar cache do sistema
--sem rasparou-npule a fase de raspagem
-ppreallocate pré-aloca espaço em disco antes da recuperação, ou seja, o arquivo de saída terá o mesmo tamanho do arquivo/dispositivo de entrada
-r3tente novamente setores defeituosos 3 vezes (usado na 2ª passagem em diante)
mas o problema é que o ddrescue parece não preencher setores defeituosos à medida que ocorrem. Com -p definido, parece resultar em todo o preenchimento no final do arquivo, não mantendo os deslocamentos dos dados desde o início do arquivo conforme necessário.
Este parece ser o caso, pois o ddrescue foi escrito para tentar economizar espaço em disco, de modo que os setores defeituosos sejam truncados e adicionados se os setores defeituosos forem lidos com êxito nas passagens subsequentes. Definir -p apenas cria um arquivo de saída do mesmo tamanho do arquivo de entrada para economizar espaço, não para preencher os dados. O conteúdo da saída com -p set ou unset será, portanto, idêntico, ou seja, não preenchido até o final do arquivo.
Pergunta
Então minha pergunta é de três partes
é correto que o ddrescue NÃO preencha o arquivo recuperado mesmo com -p definido?
Existe alguma maneira de acolchoá-lo? Na minha pesquisa na Internet, li um comentário (vou encontrá-lo novamente e adicionar) que o arquivo de log criado pelo ddrescue poderia ser usado por um script para preencher os locais relevantes. Alguma ideia de como?
e
- você conhece algum comando/programa/script melhor para fazer o que estou tentando fazer - recuperação máxima de dados por meio de várias passagens de leitura de um disco corrompido com preenchimento de setores defeituosos?
Estou usando o Ubuntu 18.04, a versão dd é (coreutils) 8.28 e a versão GNU ddrescue é 1.22, ambas dos repositórios do Ubuntu.
Obrigado como sempre por qualquer ajuda
Responder1
GNU ddrescueé a ferramenta certa para a recuperação que você está tentando.
1) é correto que o ddrescue NÃO preencha o arquivo recuperado mesmo com -p definido?
Esta presunção está incorreta. Você pode estar confuso como manualdizendo isto:
Ddrescue não grava zeros na saída quando encontra setores defeituosos na entrada e não trunca o arquivo de saída se não for solicitado.
Significa apenas que zeros não são escritos no lugar de setores defeituosos. O que quer que deveria estar nesses setores defeituosos simplesmente não é preenchido. Se você estiver gravando em um disco ou arquivo vazio,as áreas não escritas no destino serão lidas como zeros(bytes nulos).
Além disso, a opção -p/ --preallocatenão tem nada a ver com "preenchimento". Significa "pré-alocar". Em sistemas de arquivos suportados, a opção garante que você tenha espaço em disco suficiente no destino para armazenar o disco de origem.
2) Existe alguma maneira de acolchoá-lo?
A saída do arquivo pelo GNU ddrescue tem logicamente o mesmo layout do disco de origem. Um bloco lido da origem vai para a mesma posição no destino. Você pode até reverter toda a recuperação ( -R/ --reverse) e os blocos serão preenchidos ao contrário, ainda nos lugares certos.
3) você conhece algum comando/programa/script melhor para fazer o que estou tentando fazer - recuperação máxima de dados por meio de múltiplas passagens de leitura de um disco corrompido com preenchimento de setores defeituosos?
GNU ddrescue faz exatamente o que você deseja. Ele pode fazer várias passagens ( -r/ ), e o "preenchimento" desejado de setores defeituosos é o comportamento padrão do GNU ddrescue. De--retry-passes=no manual:
Se o arquivo de saída for um arquivo normal criado pelo ddrescue, as áreas marcadas como setor defeituoso conterão zeros.
Para ser perfeitamente claro e abordar sua preocupação de que uma leitura bem-sucedida seguida de uma leitura incorreta seria "preenchida" com nulo,ddrescue não tentará reler uma leitura bem-sucedida―não há necessidade porque os dados já foram recuperados. O mapfile é como o ddrescue sabe o que já recuperou e não conseguiu recuperar.