If you check the exit code from rsync and it returned 0 (success), no errors should have occurred. In a shell script, immediately after rsync's execution, it would be in
$? for bourne-likes and
$status for [t]csh. No output on stderr is similarly a good sign, but I trust it less than the exit code.
Depending on the failure, backups using
--link-dest may not have had hardlinks created, but doing checksum scans would detect this. If a hardlink is created during rsync, it had already determined that the files are identical and did not transfer the file's data at all. There is no way a hardlinked file would checksum differently in an incremental vs full backup.
If a full backup failed, all of the incrementals based on that full backup are suspect. Generally speaking, rsync is clever enough to figure out differences regardless of full backup completion, and in this case, your subsequent incrementals will be significantly larger than normal. I would still be very concerned about any failure in the backup process.
A word of caution,
-c (checksum) will force a full re-read of every selected file on both the source and destination systems, regardless of datestamp or filesize, and will greatly increase the time and system io required on both ends.
edit: To answer your subsequent question,
time will pass the return code from its child program through to its parent unless there was an error running
time, for example the user SIGTERM'd
The time command returns when the program exits, stops, or is terminated by a
signal. If the program exited normally, the return value of time is the
return value of the program it executed and measured. Otherwise, the return
value is 128 plus the number of the signal which caused the program to stop