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/

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... >.<