I want to use rsync to backup a couple of Windows systems to a central
point. To this end I installed the "DeltaCopy" implementation of an
rsync server on the Windows boxes. On the central server I have rsync
3.0.7 running on a Debian GNU/Linux distribution. (I also have a similar
configuration but with a QNAP - a NAS with bells on - as the central
backup point. Since both exhibit the same behaviour I'm going to stay
with the more common scenario.) I also have rsnapshot in the mix but to
keep things simple I'm going to ignore that for now.
A cut-down example rsync command could be something like this,
rsync -avxH --delete --numeric-ids --relative --delete-excluded
--modify-window=1 --password-file=/etc/rsnapshot.secret
--link-dest=/backup/last/ rsync://rsync@windows/DocumentsAndSettings
/backup/this/
If this call contacts a Linux based system, the hard links between files
in /backup/last/... and their unchanged counterparts in /backup/this/
are created by the --link-dest option as expected. If this contacts a
Windows based system running DeltaCopy they are not linked. Ever.
I believe I have narrowed this down to a mismatch between the UID/GID
values on the Windows side and the Linux side. What appears to be
happening is that the Windows system is providing UID/GID values in a
range that cannot be handled by the Linux system, and so it is
truncating/converting them to 0/0. Then, when the next rsync runs, the
UID/GID values provided by the Windows system do not match 0/0 and so
copy is made of the file. (This is fast as it's built from the
--link-dest item, but nevertheless it's a copy.) The resulting copy
cannot have its UID/GID values applied correctly as they are out of the
valid range on the Linux side, and so they are again truncated/converted
to 0/0. And so on.
The work-around is to apply --no-owner and --no-group to the rsync
command line, at which point the files are owned by the caller of the
rsync command on the central server and --link-dest can work as
expected. However, I believe a better solution would, if possible, be to
force the UID/GID values into a valid range before comparing them to an
existing file referenced via --link-dest.
Additional comments -
1. I haven't tried an alternative Windows client (e.g. cygwin/rsync) as
this is outside the scope of what I can change on these systems.
Therefore I cannot be sure whether this is a client or server issue,
i.e. I cannot confirm that this fault report belongs to rsync rather
than to DeltaCopy
2. I did get a UID/GID range error at one point but I can neither
reproduce it nor remember it sufficiently accurately to want to cite it here
Any other thoughts, please? Should I report this as a bug?
Cheers,
Chris
--
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
