O dd faz algum tipo de verificação?

Estou usando ddpara copiar dados de um disco rígido antigo para um novo. Quero ter certeza de que a integridade dos dados é segura.

Nesta resposta , Gilles diz

Se o [dd] foi finalizado com sucesso, o backup está correto, salvo uma falha de hardware…

O que isso significa exatamente? Tem ddalgum tipo de verificação integrada?

Se eu fosse usar o rsync, também executaria uma segunda passagem --checksumpara verificar. Esse tipo de paranóia é justificado?

ddou qualquer outro aplicativo não possui "algum tipo de verificação integrada" no sentido em que você provavelmente está pensando: ele não lê os dados da mídia de armazenamento para comparar com o que foi escrito. Esse é o trabalho do sistema operacional.

Não é realmente possível fazer uma verificação de leitura no hardware a partir de um aplicativo. Funcionaria em alguns cenários, mas na maioria dos casos não alcançaria nada. O aplicativo pode ler novamente o que acabou de escrever se estiver gravando diretamente em uma mídia de armazenamento , mas isso normalmente seria lido em um cache na memória, o que não daria nenhuma garantia útil. No exemplo que você cita , ddestá gravando em um canal e, nesse caso, não tem controle sobre o que acontece com os dados mais abaixo na linha. No seu exemplo rsync, uma segunda passagem dersync --checksum é inútil: em teoria, ele pode pegar um erro, mas, na prática, se ocorrer um erro, a segunda passagem provavelmente não reportará nada de errado; portanto, você está desperdiçando esforço em algo que na verdade não fornece uma garantia útil.

No entanto, as aplicações não verificar o que acontece com os dados, no sentido de que eles verificar se o sistema operacional tem a responsabilidade aceita para os dados. Todas as chamadas do sistema retornam um status de erro. Se uma chamada do sistema retornar um status de erro, o aplicativo deverá propagar esse erro para o usuário, geralmente exibindo uma mensagem de erro e retornando um status de saída diferente de zero.

Cuidado que ddé uma exceção: dependendo dos parâmetros da linha de comandos, ddpode ignorar alguns erros . Isso é extremamente incomum: ddé o único comando comum com essa propriedade. Use em catvez de dd, dessa forma, você não corre o risco de corrupção e pode muito bem ser mais rápido .

Em uma cadeia de cópia de dados, dois tipos de erros podem surgir.

• Corrupção: um pouco é invertido durante a transferência. Não há como verificar isso no nível do aplicativo, porque se isso acontecer, é devido a um erro de programação ou erro de hardware que provavelmente causa a mesma corrupção ao ler novamente. A única maneira útil de verificar se não ocorreu essa corrupção é desconectar fisicamente a mídia e tentar novamente, de preferência em outro computador, caso o problema esteja com a RAM.
• Truncamento: todos os dados copiados foram copiados corretamente, mas alguns deles não foram copiados. Este é vale a pena conferir, por vezes, dependendo da complexidade do comando. Você não precisa ler os dados para fazer isso: basta verificar o tamanho.

Não, ddnão faz uma verificação explícita. Se você quiser / precisar de uma cópia forense do seu disco ou de qualquer parte dele, use dcfldduma versão aprimorada dddesenvolvida pelo Laboratório de Computação Forense do Departamento de Defesa dos EUA.

A única maneira de ter "certeza" é fazer um passo adicional de leitura e comparação (depois de eliminar os caches).

Além disso, dddetecta erros de leitura e gravação da mesma maneira que todos os outros programas ... funciona se as unidades (e outros componentes envolvidos) reportarem erros; para unidades que aceitam dados silenciosamente sem realmente escrevê-los, você está sem sorte.

Esse tipo de paranóia é justificado?

Se você não pode confiar no seu hardware, as coisas ficam complicadas ...

Sim, o hardware defeituoso pode inserir bits de erro aleatórios nos dados em uma taxa de 1 bit por número de megabytes, isso é possível e ocorre às vezes na prática.

Normalmente, uso o hash md5 ou sha1 para verificar se os dados estão intactos, relendo a origem e o destino, por exemplo:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

Isso pressupõe que os dados são muito maiores que o cache do sistema de arquivos; caso contrário, pode ser necessário reiniciar o sistema para verificar os dados reais no meio e não o conteúdo do cache, ou usar outro sistema para isso.

De man dd:

Quando concluído, dd exibe o número de blocos de entrada e saída completos e parciais, registros de entrada truncados e blocos de troca de bytes de comprimento ímpar para a saída de erro padrão.

Um bloco de entrada parcial é aquele em que menos do que o tamanho do bloco de entrada foi lido. Um bloco de saída parcial é aquele em que menos do que o tamanho do bloco de saída foi gravado. Blocos de saída parcial para dispositivos de fita são considerados erros fatais. Caso contrário, o restante do bloco será gravado. Blocos de saída parciais para dispositivos de caracteres produzirão uma mensagem de aviso.

ddverifica se os tamanhos dos blocos de entrada / saída correspondem toda vez que copia um bloco. Caso contrário, ele lida com o erro com um aviso ou erro fatal (substituído por noerror). É por isso que ddfunciona praticamente o tempo todo.

Ainda assim, ele não substitui a verificação manual da integridade do seu disco. Se a informação é valiosa para você, sim, sua paranóia é justificada . Execute uma verificação manual assim que ddterminar.