
Estou usando dd
para copiar dados de um disco rígido antigo para um novo. Quero ter certeza de que a integridade dos dados está segura.
Nistoresponder, Gilles diz
Se [dd] for finalizado com sucesso, então o backup está correto, salvo uma falha de hardware…
O que isso significa exatamente? Possui dd
algum tipo de verificação integrada?
Se eu usasse o rsync, --checksum
também executaria uma segunda passagem para verificar. Esse tipo de paranóia é justificado?
Responder1
dd
ou qualquer outro aplicativo não possui “algum tipo de verificação integrada” no sentido que você provavelmente está pensando: ele não lê os dados do meio 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 do hardware a partir de um aplicativo. Funcionaria em alguns cenários, mas na maioria dos casos não resultaria em nada. O aplicativo pode ler o que acabou de escreverse estiver gravando diretamente em uma mídia de armazenamento, mas isso normalmente seria lido de um cache na memória, o que não daria nenhuma garantia útil. Emo exemplo que você cita, dd
está gravando em um canal e, nesse caso, não tem controle sobre o que acontece com os dados mais adiante. No seu exemplo de rsync, uma segunda passagem rsync --checksum
é inútil: em teoria, poderia detectar um erro, mas na prática, se um erro acontecer, a segunda passagem provavelmente não reportaria nada de errado, então você está desperdiçando esforço em algo que na verdade, não oferece uma garantia útil.
No entanto, aplicaçõesfazerverificar o que acontece com os dados, no sentido de que verificam se o sistema operacional aceitou a responsabilidade pelos 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 ao usuário, geralmente exibindo uma mensagem de erro e retornando um status de saída diferente de zero.
Cuidado, isso dd
é uma exceção: dependendo dos parâmetros da linha de comando,dd
pode ignorar alguns erros. Isto é extremamente incomum: dd
é o único comando comum com esta propriedade. Use cat
em vez de dd
, assim você não corre o risco de corrupção epode muito bem ser mais rápido.
Numa cadeia de cópia de dados, podem surgir dois tipos de erros.
- Corrupção: um bit é invertido durante a transferência. Não há como verificar isso no nível do aplicativo, porque se isso acontecer, será devido a um bug de programação ou erro de hardware que provavelmente causará a mesma corrupção durante a leitura. A única maneira útil de verificar se tal corrupção não ocorreu é desconectar fisicamente a mídia e tentar novamente, de preferência em um computador diferente, caso o problema esteja na RAM.
- Truncamento: todos os dados copiados foram copiados corretamente, mas alguns dados não foram copiados. Esteévale a pena conferir algumas vezes, dependendo da complexidade do comando. Você não precisa ler os dados para fazer isso: basta verificar o tamanho.
Responder2
Não, dd
não faz uma verificação explícita. Se você deseja/precisa de uma cópia verificada forense do seu disco ou de qualquer parte dele, use dcfldd
uma versão aprimorada dd
desenvolvida pelo Laboratório de Computação Forense do Departamento de Defesa dos EUA.
Responder3
A única maneira de ter "certeza" é fazer uma passagem adicional de leitura e comparação (depois de descartar os caches).
Além disso, dd
detecta erros de leitura e gravação da mesma forma que todos os outros programas... funciona se as unidades (e outros componentes envolvidos) relatarem erros; para unidades que aceitam dados silenciosamente sem gravá-los, você está sem sorte.
Esse tipo de paranóia é justificado?
Se você não pode confiar que seu hardware seja confiável, as coisas ficam complicadas...
Responder4
De man dd
:
Quando terminar, 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 foi lido menos do que o tamanho do bloco de entrada. Um bloco de saída parcial é aquele em que foi gravado menos do que o tamanho do bloco de saída. Blocos de saída parciais para dispositivos de fita são considerados erros fatais. Caso contrário, o resto do bloco será escrito. Blocos de saída parciais para dispositivos de caracteres produzirão uma mensagem de aviso.
dd
verifica se os tamanhos dos blocos de entrada/saída correspondem sempre que copia um bloco. Caso contrário, ele trata o erro com um aviso ou erro fatal (substituído por noerror
). É por isso que dd
funciona praticamente o tempo todo.
Ainda assim, isso não substitui a verificação manual da integridade do seu disco. Se a informação for valiosa para você, então sim,sua paranóia é justificada. Execute uma verificação manual quando dd
terminar.