Se o comando foi finalizado com êxito, o backup está correto, exceto uma falha de hardware (que pode afetar igualmente qualquer verificação que você possa realizar). Mais tarde, pode 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 em que 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.) Então, aqui está uma leitura erro de dd
seria ignorado. No bash, defina a opção pipefail
para relatar erros de todas as partes do pipeline.
Além disso, tenha em atenção que dd bs=…
ignora alguns erros e dd
é geralmente mais lento que as alternativas . Eu recomendo não usar dd
: não tem nenhum benefício apenas copiar um arquivo inteiro. Ao contrário do que você pode ter lido em algum lugar, dd
não é um comando de acesso a disco de baixo nível com propriedade especial, não há absolutamente nenhuma mágica em dd
, a mágica está em /dev/hda
.
shopt -s pipefail
set -e
</dev/hda buffer -s 64k -S 10m | ssh myuser@myhost "cat > ~/image.img"
No entanto, se você quiser verificar o backup, a melhor maneira é pegar uma soma de verificação criptográfica em cada lado e compará-los. 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. Tudo o que você alterar em /dev/hda
, incluindo a montagem e desmontagem de 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ê quiser verificar a integridade mais tarde, anote a soma de verificação do disco no momento do backup em algum lugar.