The way you generally deal with this problem is the way you deal with any other situation in which you want to roll back to a previous version of a file: Incremental backups.
The idea here is that you only actually copy the file when the contents change. For any other copy of the file on the backup media, you just refer to a previous revision. This allows you to go back to a previous revision of the file if the current one turns out to be corrupted, the idea of course being that if you don't notice the corruption in time then the file probably wasn't very important to begin with.
rsync supports this (at least on *nix) with the
--link-dest command-line parameter.
For this to work nicely, you also need something to clean up old copies, which rsync doesn't; you'd need something else for that. Otherwise your disk will eventually fill up and you will have to delete files from the target media manually.
And to answer the direct question: rsync has no real handling of corrupted files. It probably will handle files that cannot be read, unless you are running it in in-place replace mode, but it isn't going to look at that JPEG image or PDF document and determine that it is malformed causing it to look weird when rendered. That's just not its job.
Compare this note in an answer to Why is RAID not a backup? on Server Fault, by Jared Oberhaus:
Will a backup refuse to copy a corrupt file?
Even if a backup copies corrupt or bad data, the point of a backup is that you can and should have multiple copies. For instance, last hour, yesterday, last week, etc. You can get a similar effect from using rotating snapshots on your storage device.
and related, in the words of Jörg W Mittag in another answer to the same question, highlighting the difference between redundancy and backups:
If you accidentally overwrite your PhD thesis with garbage, redundancy ensures that you have multiple copies of garbage, in case one gets bad. A backup ensures that you can restore your PhD thesis.