rsync is by far not the most efficient solution out there nowadays, but it cannot be denied that it does work.
It can run over ssh ('rsync ... user@host:/path/to/file' will pass the 'user@host' bit to ssh and then use the resulting link) or rsync (which is unencrypted but a fair bit faster).
What I do to move (not copy) data around my LAN and know that the file has transferred okay is to
rsync -P -a -z file rsync://server/module/path
and then after this has completed
rsync -P -a -z file rsync://server/module/path -c --remove-source-files
The first just dumbly copies the data; the second uses checksum diffing to copy the failed bits.
If you have a pathologically bad network, you could use 'rsync ..... -c' and only when rsync says there were no differences use --remove-source-files. (You can get transfer statistics with the following extra commandline parameters.)
I also add
-v --info=all --debug=all
onto the end of my commands, because I like the extra info this spits out. Protip, DO NOT use -vv (ie verbosity level 2) with info/debug=all, it will tell you about every single hash block match :D
For large files the comparison will take some time because rsync uses a fairly dumb design and a very slow checksum algorithm (there are faster alternatives with better (lower) collision rates out there). But rsync is like perl, it will almost always exist where you need it.
I don't consider rsync a particularly modern tool, and it's given me a lot of ideas on how to write a better implementation at some point. But it's a ton easier than sha1summing hundred-gigabyte tar files, which is what I used to do... >.<