rsync doesn't delete any files at the destination side. To make
rsync delete files at all, you need to use at least one of the delete options.
If you don't care when files are being deleted, just use
--delete and leave the choice to
rsync. You can combine
--delete with other delete options (this doesn't conflict) but you don't have to as all other delete options already imply
--delete-before works as follows:
rsync looks which files are present at the source and which files are present at the destination, deletes all files found at the destination but not at the source and then starts the actual synchronization. This order is useful if the destination has little storage space as it will first free up more disk space at the destination before starting transferring any new files. The downside is that
rsync will require more memory to perform the operation and the whole operation is a two step process and thus slower.
--delete-during works as follows:
rsync immediately starts to synchronize files and when it comes across a file that exists only at the destination, it is deleted. That way there is no speed penalty and also no additional memory is required. The downside is that it may happen that first a lot of new files are copied to the destinations before removed files are being deleted, so the destination may require much more disk storage space during the operation than it requires in the end once the entire operation is done.
--delete-after works as follows: First synchronize all files, then perform the same operation that
--delete-before performs before the synchronization phase. This is the worst choice in most common cases as it requires most memory, most disk space at the destination, and it is slower as it is a two step process; basically it combines all disadvantages of the other two methods. This option mainly exists for the case that you are using "merge files" (what merge files are and how they work is beyond the scope of this answer). As these files may contain rules for files to be excluded during delete, new merge files must be copied before the deletion phase if their content shall be considered during the deletion phase. Unless that is a requirement,
--delete-after has no advantage.
--delete-delay is a rather new option (it's not available in
rsync 2.6.9, which is still the default in macOS 10.15 for example). It works like
--delete-during, except that it won't delete files immediately but after the synchronization is done, so it is a hybrid of
--delete-after. The advantages are that it is faster than
--delete-after and still supports merge files correctly, the disadvantage is that it requires more memory and disk space during the synchronization just like
rsync to not just delete files that are missing at the source but to also delete files at the destination that were excluded from synchronization (
--exclude-from), regardless if these files would actually exist at the source or not.
Which one shall I use?
If you use merge files, you probably want to use
--delete-delay, if available, otherwise
If you don't use merge files, you usually want to use
--delete-during which will be fastest.
Only if the storage space at the destination is very tight and the data to be synchronized just barely fits there, you may want to use
--delete-before instead as in that case
--delete-during could fail as the destination could run out of disk space yet
--delete-before would then probably still succeed.
As for memory consumption, that's usually not an issue at all with modern systems which have plenty of spare memory available. It may be an issue with tiny embedded devices but those typically don't use
rsync in the first place for file synchronization and also have very little spare disk space, too.