Bryan Hoyt | Brush Technology
2011-Mar-11 22:30 UTC
Unintuitive backwards-incompatible behaviour with rsync -a --link-dest --size-only
I use rsync to backup my system, using a command-line such as the following:> rsync [src] [dst] -a --link-dest --size-onlyIn this case, [src] is produced by a command that makes no attempt to preserve timestamps ("svnadmin hotcopy", in this case). That's why I use --size-only. Here's the rub: identical files aren't hard-linked like I expect them to be. They're full copies. And the reason is that the timestamps are different (I've tested that in various ways, and am able to produce correctly hardlinked backups by manually forcing the timestamps to be identical.) Is this because --size-only doesn't affect the behaviour of --link-dest, but only the transfer comparison? Should it affect --link-dest in a similar way? I've worked around this issue by specifying "--no-times" on the rsync command line. This does what I want, although as far as I can make out, it's only due to a side-effect that it actually works (I don't really care whether timestamps are preserved or not, in this case -- they're bogus anyway). The other weird thing is that --size-only *used* to work as I expect, with identical command-line, leaving off the "--no-times" flag. I've had this backup system in place for a few years, and it's always worked smoothly. Then when I upgraded from an old version of Redhat to a recent version of Ubuntu (10.10), the backups suddenly shot up massively in size, for this reason. I have not changed the rsync command line before or after the Ubuntu upgrade. Has rsync's behaviour changed in this respect in the last 2-3 years? Is this a bug? - Bryan -- PS. Check out the Brush newsletter: *Subscribe or read our previous newsletters* <http://brush.co.nz/newsletters> Bryan Hoyt, *Web Development Manager* -- Brush Technology *Ph:* +64 3 741 1204 *Mobile:* +64 21 238 7955 *Web:* brush.co.nz -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20110312/3842f6ce/attachment.html>
Bryan Hoyt | Brush Technology
2011-Mar-17 00:34 UTC
Unintuitive backwards-incompatible behaviour with rsync -a --link-dest --size-only
Is anybody able to shed insight on this issue for me? Thanks in advance! - Bryan On Sat, Mar 12, 2011 at 11:30, Bryan Hoyt | Brush Technology < bryan at brush.co.nz> wrote:> I use rsync to backup my system, using a command-line such as the > following: > > rsync [src] [dst] -a --link-dest --size-only > > In this case, [src] is produced by a command that makes no attempt to > preserve timestamps ("svnadmin hotcopy", in this case). That's why I use > --size-only. > > Here's the rub: identical files aren't hard-linked like I expect them to > be. They're full copies. And the reason is that the timestamps are different > (I've tested that in various ways, and am able to produce correctly > hardlinked backups by manually forcing the timestamps to be identical.) > > Is this because --size-only doesn't affect the behaviour of --link-dest, > but only the transfer comparison? Should it affect --link-dest in a similar > way? > > I've worked around this issue by specifying "--no-times" on the rsync > command line. This does what I want, although as far as I can make out, it's > only due to a side-effect that it actually works (I don't really care > whether timestamps are preserved or not, in this case -- they're bogus > anyway). > > The other weird thing is that --size-only *used* to work as I expect, with > identical command-line, leaving off the "--no-times" flag. I've had this > backup system in place for a few years, and it's always worked smoothly. > Then when I upgraded from an old version of Redhat to a recent version of > Ubuntu (10.10), the backups suddenly shot up massively in size, for this > reason. I have not changed the rsync command line before or after the Ubuntu > upgrade. > > Has rsync's behaviour changed in this respect in the last 2-3 years? > > Is this a bug? > > - Bryan > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20110317/1ff9051e/attachment.html>