Hello. This is my first post here ;) I've been using rsync heavily for quite some time. For one, we use it to perform offline backups of numerous machines into single location. Since the systems are basically identical, it's wise to keep only different files, hard-linking identical ones. That worked well for many years, till rsync-3 were out.
The procedure is like this: on the server-to-be-backed-up there's a "previous" directory, which gets compared with "current" using rsync, to generate a batched update. That update, or "delta", is sent to the central server (backup destination). There, it is applied to this system's "previous" state, to get the "current" one. This alone works as expected. The only difference between this version (which is an intended usage) and my actual usage is that I add extra --link-dest argument on the receiving end, to simplify finding identical files. So the receiving end, unlike the sending one, has two --link-dests -- one usual for the "previous state", and one extra, for "other machine" current state. Example command lines: sender: rsync -aHRSx \ --link-dest=$last \ --write-batch=batch \ directory... \ $cur receiver: rsync -aHRS \ --read-batch=batch \ --link-dest=$other \ --link-dest=$last \ $cur So the only one additional option is given: extra --link-dest=$other, for current backup dir of another machine. With this option, it fails on regular basis, in batches on the same place. Like this: (Skipping batched update for "etc/samba/smbpasswd") (No batched update for "etc/samba/smbpasswd") rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1526) [generator=3.0.7] Here are the files, with md5sums: -rw------- 2 root root 6118 Mar 16 07:22 $other/etc/samba/smbpasswd e473d16a8abad10a3f08e3fa96b5ed37 -rw------- 1 root root 6039 May 12 17:50 $last/etc/samba/smbpasswd d7bc141404920cd330f1ae0aff96389f -rw------- 1 root root 6039 Май 14 10:35 $NEW/etc/samba/smbpasswd d7bc141404920cd330f1ae0aff96389f where $NEW is the actual file being backed up, which should be in the receiving batch. Note that the new file is of the same _size_ as in $other, but with different content. As you can see, $last and $new has the same content but different timestamps. I suspect it is due to some bug in older rsync, or maybe some my inaccuracy - I don't know, but the fact it that yes, some dates mismatches. When I set the date for the $last to match the one in the batch, it works. But what is more interesting is that it also works when I remove usage of the extra --link-dest, even with the wrong timestamp. It updates the timestamp and moves on. But with extra --link-dest in place, it fails like the above. To me it looks like the two places -- the one which checks if the "batched update" is actually necessary and the one which actually implements the update, do not match each other somehow. I'd say it's local operator/environment error, because the destination is not the same as the sender expects, if it were not working without the extra --link-dest. And what I can say for sure is that it always worked with rsync version 2. I tried to switch to v3 for serveral times, always ending up in this and reverting back to v2. Initially I tried updating rsync only on the receiving side (with immediate problem being trivial to fix by reverting back to v2 which processes the "bad" batches just fine), now I updated it on both ends, so v2 on the receiver does not work anymore, but the problem is still the same. Thanks! /mjt -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
