Using --inplace with --backup and --backup-dir does not seem to work: rsync -ax --backup --backup-dir previous destfile remotehost:/destdir/ ...or more simply: rsync -avx --stats --inplace --backup --backup-dir previous \ /etc/hosts /tmp/rsynctest/ strace watching the rsync running on the destination: [...] write(1, "160134 octets, for a total of 19296646"..., 160134) = 160134 ftruncate64(0x1, 0x1267186, 0, 0, 0x1) = 0 close(1) = 0 lstat64(0xbfffebac, 0xbfffba5c) = 0 lstat64(0xbfffa9bc, 0xbfffb9cc) = 0 rename("destfile", "previous/destfile") = 0 lstat64(0x8080780, 0xbfffb9cc) = 0 lstat64(0xbfffebac, 0xbfffba7c) = -1 ENOENT (No such file or directory) write(4, "i\0\0\10rsync: stat \"/destdir/destfile\" failed: No such file or directory (2)\n", 109 <unfinished ...> [...] With --inplace and --backup, shouldn't rsync make the backup file *before* starting the overwrite? Then it could (quote) extract the full amount of network reduction it might otherwise. I've tried it on two boxes. Slackware 8.0 (I'm ashamed to admit) glibc2.2, and Slackware 9.1 glibc 2.3, both kernel 2.6.4, rsync-2.6.3pre1.
Yes, this combination of options did not work at all right (rsync updated the file inplace and then moved the file into the backup dir -- ouch!). I've checked in a file that has the generator copy a backup during the checksum generation phase when --inplace was specified with --backup. Then, the code was further improved to use the backup file as the basis file so that the normal --inplace limits on skipping overwritten blocks was not needed. This, as you noted, makes the transfer as efficient as if --inplace was not used.