Rsync Performance – Maximizing Rsync Performance and Throughput for Directly-Connected Gigabit Servers

Normally, rsync skips files when the files have identical sizes and times on the source and destination sides. This is a heuristic which is usually a good idea, as it prevents rsync from having to examine the contents of files that are very likely identical on the source and destination sides.

--ignore-times tells rsync to turn off the file-times-and-sizes heuristic, and thus unconditionally transfer ALL files from source to destination. rsync will then proceed to read every file on the source side, since it will need to either use its delta-transfer algorithm, or simply send every file in its entirety, depending on whether the --whole-file option was specified.

--checksum also modifies the file-times-and-sizes heuristic, but here it ignores times and examines only sizes. Files on the source and destination sides that differ in size are transferred, since they are obviously different. Files with the same size are checksummed (with MD5 in rsync version 3.0.0+, or with MD4 in earlier versions), and those found to have differing sums are also transferred.

In cases where the source and destination sides are mostly the same, --checksum will result in most files being checksummed on both sides. This could take long time, but the upshot is that the barest minimum of data will actually be transferred over the wire, especially if the delta-transfer algorithm is used. Of course, this is only a win if you have very slow networks, and/or very fast CPU.

--ignore-times, on the other hand, will send more data over the network, and it will cause all source files to be read, but at least it will not impose the additional burden of computing many cryptographically-strong hashsums on the source and destination CPUs. I would expect this option to perform better than --checksum when your networks are fast, and/or your CPU relatively slow.

I think I would only ever use --checksum or --ignore-times if I were transferring files to a destination where it was suspected that the contents of some files were corrupted, but whose modification times were not changed. I can't really think of any other good reason to use either option, although there are probably other use-cases.

As far as I know, the "file-has-vanished" condition is not a fatal error condition for rsync, and the process should continue just fine. Are you saying that rsync is halting upon reporting the "vanished file" messages?

If you are backing up a live filesystem, it is always possible to get the "vanished" message from rsync. Between the time that rsync adds a file to its transfer list and the time that rsync actually gets around to reading it, a file can "vanish" for any number of legitimate reasons (e.g. a temporary lock file was removed, or a file was renamed). Note that some applications work around limitations in NFS file locking by creating and removing hidden lock files, and it's possible that rsync may be seeing some of those.

I would suggest to keep your source filesystem as quiescent as possible while it is being backed up. Ideally, no one other than the backup process should be accessing it, but I realize that that may not be feasible. If your source filesystem is on an LVM logical volume, then you could consider creating a read-only snapshot to use as your backup source.