Hi Bob, I'll try the option you mentioned to check if it can solve the problem.
I've got some more clues after this weekend. Of course, nobody has connected to the machine (i.e. open a session) during the weekend. But on each evening when backup was running, the complete (on almost complete) /home/ folder of one (and only one) of the users was viewed by rdiff-backup as changed (in the same way I described in my former email, i.e. a IncrementSize of some bytes & no actual change). Should I suspect some Kubuntu service to create this weird things ? (something like updatedb.mlocate, even if I doubt on this particular one). Thanks for help. Regards, Matthieu > From: [email protected] > To: [email protected] > Date: 17/11/2012 23:24 > Subject: Re: [rdiff-backup-users] Weird behavior of rdiff-backup : > founding diffs while there isn't > Sent by: [email protected] > > On 11/16/2012 04:21 AM, [email protected] wrote: > > Consider I already have 2 backups done on a daily basis (let me call them > > A and B chronologically -- thus B is the current mirror). > > > > I run 'rdiff-backup --compare' just before backing up : it returns "no > > changes" > > > > I run the back up and here rdiff-backup finds thousand of files that have > > changed (viewed from session statistics) !!! > > This backup is called C and is the new mirror. > > > > When I look at the file statistics, a lot of files are marked as changed. > > The first weird thing here is that IncrementSize is not null while > > SourceSize and MirrorSize are identical (IncrementSize is always a small > > number -<128 -). > > > > For example : home/USER/.kde/share/config/katerc 1 67 67 66 > > By any chance are these all files with multiple hard links, and if so, does > this excerpt from the rdiff-backup manpage shed any light: > > --no-compare-inode > This option prevents rdiff-backup from flagging a hardlinked file > as changed when its device number and/or inode changes. This > option is useful in situations where the source filesystem lacks > persistent device and/or inode numbering. For example, network > filesystems may have mount-to-mount differences in their device > number (but possibly stable inode numbers); USB/1394 devices may > come up at different device numbers each remount (but would gener- > ally have same inode number); and there are filesystems which don’t > even have the same inode numbers from use to use. Without the > option rdiff-backup may generate unnecessary numbers of tiny diff > files. > > -- > Bob Nichols "NOSPAM" is really part of my email address. > Do NOT delete it. > > > _______________________________________________ > rdiff-backup-users mailing list at [email protected] > https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users > Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki _______________________________________________ rdiff-backup-users mailing list at [email protected] https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
