Se o comando foi finalizado com êxito, o backup está correto, exceto uma falha de hardware (que poderia afetar igualmente qualquer verificação que você possa executar). Posteriormente, poderá ficar incorreto se o hardware estiver com defeito, mas a maioria dos hardwares de armazenamento detecta corrupção.
Há uma ressalva aqui: em um pipeline, o shell não relata erros do lado esquerdo. (Isso ocorre devido a um cenário bastante comum, no qual o lado direito não precisa ler todos os dados, por exemplo some_command | head, e o lado esquerdo morre porque sua saída não é mais desejada.) Portanto, aqui um erro de leitura ddseria ser ignorado. No bash, defina a pipefailopção para relatar erros de todas as partes do pipeline.
Além disso, cuidado com isso dd bs=…ignora alguns erros e ddgeralmente é mais lento que as alternativas . Eu recomendo não usar ddnada: não há benefícios em copiar apenas um arquivo inteiro. Ao contrário do que você pode ter lido em algum lugar, ddnão há um comando de acesso ao disco de baixo nível com propriedades especiais, não há absolutamente nenhuma mágica dd, a mágica está /dev/hda.
shopt -s pipefail
set -e
</dev/hda buffer -s 64k -S 10m | ssh myuser@myhost "cat > ~/image.img"
No entanto, se você deseja verificar o backup, a melhor maneira é pegar uma soma de verificação criptográfica de cada lado e compará-las. Por exemplo:
ssh myuser@myhost "sha1sum image.img" &
sudo sha1sum /dev/hda
Verifique se as duas somas de verificação são idênticas.
Observe que isso testa se o backup e o original são idênticos no momento da verificação. Qualquer coisa que você altere /dev/hda, incluindo montar e desmontar um sistema de arquivos, mesmo sem fazer nenhuma alteração (que atualizará a última data de montagem em muitos sistemas de arquivos), alterará a soma de verificação. Se você deseja verificar a integridade posteriormente, anote a soma de verificação do disco no momento do backup em algum lugar.