If the command terminated successfully, then the backup is correct, barring a hardware fault (which could equally affect any verification you might perform). It may later become incorrect if the hardware is faulty, but most storage hardware detects corruption.
There is one caveat here: in a pipeline, the shell doesn't report errors from the left-hand side. (This is because of a fairly common scenario where the right-hand side doesn't need to read all the data, e.g.
some_command | head, and the left-hand side dies because its output is no longer wanted.) So here a read error from
dd would be ignored. In bash, set the
pipefail option to report errors from all parts of the pipeline.
Also, beware that
dd bs=… ignores some errors and
dd is often slower than alternatives. I recommend not using
dd at all: it has no benefits to just copy a whole file. Contrary to what you might have read somewhere,
dd is not a low-level disk access command with special property, there is absolutely no magic in
dd, the magic is in
shopt -s pipefail
</dev/hda buffer -s 64k -S 10m | ssh myuser@myhost "cat > ~/image.img"
Nonetheless, if you wish to check the backup, the best way is to take a cryptographic checksum on each side and compare them. For example:
ssh myuser@myhost "sha1sum image.img" &
sudo sha1sum /dev/hda
Check that the two checksums are identical.
Note that this tests whether the backup and the original are identical at the time of the check. Anything you change on
/dev/hda, including mounting and unmounting a filesystem even without making any change (which will update a last mount date on many filesystems), will change the checksum. If you want to verify the integrity later, note down the checksum of the disk at the time of the backup somewhere.