Hi Bob,
I already did such kind of investigations. ;-)
But did it again (double checking is not too much) very carefully.
First (following your advice), I look at the mirror...snapshot - which is
the current state.
I took here 2 files for example :
--------------------
File home/USER/.VirtualBox/VirtualBox.xml
Type reg
Size 1077
SHA1Digest 946f1f2da7b56fa6846df8ee33205a2f7757cf9d
ModTime 1305099285
Uid 2001
Uname :
Gid 2000
Gname :
Permissions 384
File home/USER/.VirtualBox/compreg.dat
Type reg
Size 1184
SHA1Digest bc535745ddeccc5edc4e1e6e9079d2330c72dee5
ModTime 1305099280
Uid 2001
Uname :
Gid 2000
Gname :
Permissions 420
--------------------
Then look at the mirror...diff - which was 2 backups ago, the day where
ridff-backup marked these files as changed :
--------------------
File home/USER/.VirtualBox/VirtualBox.xml
Type reg
Size 1077
SHA1Digest 946f1f2da7b56fa6846df8ee33205a2f7757cf9d
ModTime 1305099285
Uid 2001
Uname USER
Gid 2000
Gname :
Permissions 384
File home/USER/.VirtualBox/compreg.dat
Type reg
Size 1184
SHA1Digest bc535745ddeccc5edc4e1e6e9079d2330c72dee5
ModTime 1305099280
Uid 2001
Uname USER
Gid 2000
Gname :
Permissions 420
--------------------
So I think here is the key. You can see that uname is once void and once
filled with the user name.
It also appears that "faulty" changes can be of 2 sorts :
- Uname was void and is now filled
- Uname was filled and is now void
Now, running a "stat" command on a file where uname is currently void (in
rdiff mirror) correctly returns the owner name.
A strange thing remains : running a rdiff-backup --compare-at-time 2B (or
even 3B or 4B) on a folder chere files changed returns "No changes found.
Directory matches archive data.".
Notice that --compare-hash-at-time or --compare-full-at-time returns the
same.
So is it possible that documentation tells that --compare-at-time do the
same as when a backup is runned, but that uname is actually used only for
true backups and not for --compare option ?
The last weird thing is that if I browse through the "increments/" folder,
I will find a very small .diff file for each changed file.
Example with the first file listed above :
--------------------
hexdump -C VirtualBox.xml.2012-11-16T23\:50\:04+01\:00.diff
00000000 72 73 02 36 46 00 04 35 00 |rs.6F..5.|
--------------------
But this is not the most important as preventing rdiff-backup viewing
changes shall prevent also these increments to be stored.
So question is : why are these "uname" once here and once gone ?
I see 4 main differences between the working system and this one that
could lead to that :
- Hard drive is a RAID 1 (working system doesn't have RAID), but I don't
think it is the reason as it is pure hardware, and there is the FS over.
- Source partition is ext4 (working system is ext3).
- Owners (i.e. uname) are LDAP users and LDAP server isn't on the faulty
machine (it is on the working one). So users are not listed in the
/etc/passwd file.
- Kernel is 2.6 (working system is 3.2) and maybe one of the above
characteristics (or another one) is badly managed by 2.6 kernels.
Here I'm not a specialist, so if someone can help in finding the root
cause, that could be very fine. ;-)
Anyway thanks a lot for already provided very helpful answers.
Best regards,
Matthieu
> > 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).
>
> It doesn't seem likely that a user would have a home directory
consisting
> almost entirely of files with multiple hard links, so it would seem that
> something else is going on.
>
> Besides the SHA1Digest (which is not used for detecting whether a file
has
> changed), the only metadata that rdiff-backup records for an ordinary
file
> with just a single hard link is size, mtime, UID, uname, GID, gname, and
> permissions. Services that run around creating indexes of files
wouldn't
> be changing any of that.
>
> Take a look at the mirror_metadata.{timestamp}.{diff|snapshot}.gz file
for
> the prior day and compare the stored data for one of the "changed" files
> with what is stored in the current
mirror_metadata.{timestamp}.snapshot.gz.
> (I generally open a couple windows and use _zless_ on each file to do
that,
> searching for for the pathname.) If rdiff-backup thinks something
changed,
> there should be a difference there.
>
> --
> Bob Nichols "NOSPAM" is really part of my email address.
> Do NOT delete it.
>
>
> _______________________________________________
> rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
> 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 rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
