[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs

From: Robert Nichols
Subject: Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
Date: Mon, 19 Nov 2012 16:54:20 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121029 Thunderbird/10.0.10

On 11/19/2012 11:19 AM, address@hidden wrote:

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
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.

By default, rdiff-backup tries to preserve user _names_, not numeric UIDs.
This is obviously going to be a problem if one machine is able to map
UIDs to names and the other is not.  I'd look into why the faulty machine
is apparently unable to contact the LDAP server to do the mapping.  You
might see if the "--preserve-numerical-ids" option masks the problem,
but, frankly, I doubt it.

The tiny change files are basically saying, "There is no change."  You
will get that any time there is a metadata-only change.  That file is
required to exist if any change at all occurred.

Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]