First of all, regarding the "resume" part of your question, --partial just tells the receiving end to keep partially transferred files if the sending end disappears as though they were completely transferred.
While transferring files, they are temporarily saved as hidden files in their target folders (e.g. .TheFileYouAreSending.lRWzDC), or a specifically chosen folder if you set the --partial-dir switch. When a transfer fails and --partial is not set, this hidden file will remain in the target folder under this cryptic name, but if --partial is set, the file will be renamed to the actual target file name (in this case, TheFileYouAreSending), even though the file isn't complete. The point is that you can later complete the transfer by running rsync again with either --append or --append-verify.
So, --partial doesn't itself resume a failed or cancelled transfer. To resume it, you'll have to use one of the aforementioned flags on the next run. So, if you need to make sure that the target won't ever contain files that appear to be fine but are actually incomplete, you shouldn't use --partial. Conversely, if you want to make sure you never leave behind stray failed files that are hidden in the target directory, and you know you'll be able to complete the transfer later, --partial is there to help you.
With regards to the --append switch mentioned above, this is the actual "resume" switch, and you can use it whether or not you're also using --partial. Actually, when you're using --append, no temporary files are ever created. Files are written directly to their targets. In this respect, --append gives the same result as --partial on a failed transfer, but without creating those hidden temporary files.
So, to sum up, if you're moving large files and you want the option to resume a cancelled or failed rsync operation from the exact point that rsync stopped, you need to use the --append or --append-verify switch on the next attempt.
As @Alex points out below, since version 3.0.0 rsync now has a new option, --append-verify, which behaves like --append did before that switch existed. You probably always want the behaviour of --append-verify, so check your version with rsync --version. If you're on a Mac and not using rsync from homebrew, you'll (at least up to and including El Capitan) have an older version and need to use --append rather than --append-verify. Why they didn't keep the behaviour on --append and instead named the newcomer --append-no-verify is a bit puzzling. Either way, --append on rsync before version 3 is the same as --append-verify on the newer versions.
--append-verify isn't dangerous: It will always read and compare the data on both ends and not just assume they're equal. It does this using checksums, so it's easy on the network, but it does require reading the shared amount of data on both ends of the wire before it can actually resume the transfer by appending to the target.
Second of all, you said that you "heard that rsync is able to find differences between source and destination, and therefore to just copy the differences."
That's correct, and it's called delta transfer, but it's a different thing. To enable this, you add the -c, or --checksum switch. Once this switch is used, rsync will examine files that exist on both ends of the wire. It does this in chunks, compares the checksums on both ends, and if they differ, it transfers just the differing parts of the file. But, as @Jonathan points out below, the comparison is only done when files are of the same size on both ends — different sizes will cause rsync to upload the entire file, overwriting the target with the same name.
This requires a bit of computation on both ends initially, but can be extremely efficient at reducing network load if for example you're frequently backing up very large files fixed-size files that often contain minor changes. Examples that come to mind are virtual hard drive image files used in virtual machines or iSCSI targets.
It is notable that if you use --checksum to transfer a batch of files that are completely new to the target system, rsync will still calculate their checksums on the source system before transferring them. Why I do not know :)
So, in short:
If you're often using rsync to just "move stuff from A to B" and want the option to cancel that operation and later resume it, don't use --checksum, but do use --append-verify.
If you're using rsync to back up stuff often, using --append-verify probably won't do much for you, unless you're in the habit of sending large files that continuously grow in size but are rarely modified once written. As a bonus tip, if you're backing up to storage that supports snapshotting such as btrfs or zfs, adding the --inplace switch will help you reduce snapshot sizes since changed files aren't recreated but rather the changed blocks are written directly over the old ones. This switch is also useful if you want to avoid rsync creating copies of files on the target when only minor changes have occurred.
When using --append-verify, rsync will behave just like it always does on all files that are the same size. If they differ in modification or other timestamps, it will overwrite the target with the source without scrutinizing those files further. --checksum will compare the contents (checksums) of every file pair of identical name and size.
UPDATED 2015-09-01 Changed to reflect points made by @Alex (thanks!)
UPDATED 2017-07-14 Changed to reflect points made by @Jonathan (thanks!)
The last modification time of directories is preserved by -a, but you can
only see this when rsync finishes. It does not try to set the time on directories that are constantly being updated with new files.
You can test this yourself. Create a directory and set the date on it to yesterday, then copy it with rsync:
$ mkdir d1 d2
$ ls -ld d1
drwxr-xr-x 2 40 Nov 4 14:41 d1
$ touch -d 'yesterday' d1
$ ls -ld d1
drwxr-xr-x 2 40 Nov 3 14:41 d1
$ rsync -i -avR d1 d2
$ ls -ld d1 d2/d1/
drwxr-xr-x 2 40 Nov 3 14:41 d1
drwxr-xr-x 2 40 Nov 3 14:41 d2/d1/
The d2/d1 dir has yesterday's date. We can override it and see if rsync
fixes things:
$ touch d2/d1
$ ls -ld d1 d2/d1/
drwxr-xr-x 2 40 Nov 3 14:41 d1
drwxr-xr-x 2 40 Nov 4 14:42 d2/d1/
$ rsync -i -avR d1 d2
.d..t...... d1/
$ ls -ld d1 d2/d1/
drwxr-xr-x 2 40 Nov 3 14:41 d1
drwxr-xr-x 2 40 Nov 3 14:41 d2/d1/
rsync -i shows the timestamp is wrong on d2/d1 and fixes it.
Best Answer
To resume an interrupted copy, you should use
rsync --append. From the man page's explanation of--append:Option
--inplacemakesrsync(over)write the destination file contents directly; without--inplace,rsyncwould:The normal mode of operation mainly prevents conflicts with applications that might have the destination file open, and a few other mishaps which are duly listed in the
rsyncmanpage.Note that, if a copy/update operation fails in steps 1.-3. above,
rsyncwill delete the temporary destination file; the--partialoption disables this behavior andrsyncwill leave partially-transferred temporary files on the destination filesystem. Thus, resuming a single file copy operation will not gain much unless you called the firstrsyncwith--partialor--partial-dir(same effect as--partial, in addition instructsrsyncto create all temporary files in a specific directory).