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. Such files will exist as hidden files in their target folders (e.g.
.TheFileYouAreSending.lRWzDC), or a specifically chosen folder if you also set the
--partial doesn't facilitate resuming a failed or cancelled transfer. Notably, a cancelled transfer (aborted with Ctrl+C) will stop the operation gracefully and the receiving end will actually delete the unfinished partial file from the target. The point of partial files is to avoid polluting the target with files that look ok but aren't (yet).
So, first of all, if you're moving large files and you want the option to cancel the rsync operation at will and resume later where you left off, you need to use the
--append switch. This will append data to smaller files that exist in the target with the same name rather than replace them with the source's version.
--append 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.
Note that if you want to be able to Ctrl+C a running rsync operation and resume it later, you should not use
--partial as well, because as mentioned, Ctrl+C is a graceful way of cancelling the operation and it will cause rsync to delete the partial file on 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
--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.
This is a bit computationally heavy on both ends initially, but can be extremely efficient to reduce network load if for example you're frequently backing up very large 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
If you're using rsync to back up stuff often, using
--checksum can be very benificial,
--append probably not, unless you're in the habit of sending large files that continously grow in size but are never modified once written (and
--checksum would work just as well as
--append, 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 always compare the contents (checksums) of every file, regardless of size or attributes.