Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
I just did some testing and found that the --preserve-numerical-ids option does not seem to affect whether those tiny increment files get created. Case 1: If, in the most recent backup, a file is recorded _without_ a user name, then a subsequent backup run that _does_ have a UID-name mapping for that UID will _not_ see that as a change, and that is true regardless of whether the --preserve-numerical-ids option is used. Case 2: If the most recent backup for a file _does_ have a user name recorded, then a subsequent backup run that _cannot_ map that UID to a name _will_ see that as a change and will create a tiny increment file, and that again is true regardless of whether the option to preserve numerical ids is used. Hi Bob, After my own tests, it seems the --preserve-numerical-ids option doesn't solve completely the problem, but however helps to shorten the backup time. With the option enabled, I have a smaller number of changed files. From what I see, I had files considered as changed in both Case 1 Case 2 without the option, and only in Case 2 with the option. This is a little bit different from what you found during your own tests, but it is what I observed. Anyway, I will thus shift one of the backup at a different time and problem will very probably be fixed. Once again thanks a lot for your helpful support. Best regards, Matthieu ___ 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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
On 11/21/2012 03:26 AM, matthieu.riot...@skf.com wrote: From: rnicholsnos...@comcast.net As I said, I have doubts about whether that will help. The names are still recorded in the mirror_metadata file even when --preserve-numerical-ids is used. On my side I think is that it could work. Even it should work if option description in the manual is correct. ;-) That's why I want to try it. Actually I will then time shift one of the backup, but keep this option as a safety option if it works. I just did some testing and found that the --preserve-numerical-ids option does not seem to affect whether those tiny increment files get created. Case 1: If, in the most recent backup, a file is recorded _without_ a user name, then a subsequent backup run that _does_ have a UID-name mapping for that UID will _not_ see that as a change, and that is true regardless of whether the --preserve-numerical-ids option is used. Case 2: If the most recent backup for a file _does_ have a user name recorded, then a subsequent backup run that _cannot_ map that UID to a name _will_ see that as a change and will create a tiny increment file, and that again is true regardless of whether the option to preserve numerical ids is used. -- 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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
From: rnicholsnos...@comcast.net
To: rdiff-backup-users@nongnu.org
Date: 19/11/2012 23:54
Subject: Re: [rdiff-backup-users] Weird behavior of rdiff-backup :
founding diffs while there isn't
Sent by: rdiff-backup-users-bounces+matthieu.rioteau=skf@nongnu.org
On 11/19/2012 11:19 AM, matthieu.riot...@skf.com 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
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
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.
___
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
Hi Bob,
I also think problem is definitely LDAP, more precisely that machine is
not able to get access to LDAP server during a time lap.
And I think I found the reason (actually when waking up on this morning
(seems it was good to sleep on it). ;-)
The 2 machines are starting their respective backup at the same hour and
the one with the LDAP server is shutting it down during backup
(voluntarily) to prevent partial/corrupted data backup.
Thus the other machine is probably not able to resolve user names during a
small time.
So a good way to fix the issue will probably to postpone one the backup to
an hour where I'm sure that the other one is no more running.
However I think that the --preserve-numerical-ids option that you
suggested can also do the job. So I have add it to the rdiff-backup so it
will be tested during next backup.
Then only I will time shift one of the backup, but if the option is well
working, that will be an extra data-safety feature.
When I will have test everything, I will keep you updated so all your
efforts finally get an answer (you can expect it by the end of the week).
:-)
Here I should say I'm a little bit confused to have not think about that
before posting on the mailing list (maybe it could have preserve your
time)... :-|
So I'm more than very thankful to you for all your complete and helpful
answers. ;-)
Thanks a lot, I will keep you updated very soon.
PS : one small thing I can share. During investigations, I often have to
analyze file_statisticsdata.gz files. Thus I quickly use this
practical bash line :
---
user@machine:~$ (gunzip -d | gawk -F '{if ($0
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
Hi Nicolas, I do not suspect any hardware failure (as this machine is running very fine), but will nevertheless carefully check it. Thanks for the tip. Regards, Matthieu From: nico...@jungers.net To: rdiff-backup-users@nongnu.org Date: 17/11/2012 18:18 Subject: Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't Sent by: rdiff-backup-users-bounces+matthieu.rioteau=skf@nongnu.org Hi Matthieu, I had only a quick read of your mail, but for me it smells hardware problem. Have you cross-checked your cables, interfaces and storage medium? Regards, Nicolas On 2012-11-16 11:21, matthieu.riot...@skf.com wrote: Hi all, I recently decided to choose rdiff-backup as backup tool on 2 Linux machines. One is running it perfectly. But the other one has a strange behavior when running rdiff-backup. Actually, it find differences in a lot of files while there isn't any. This leads to rdiff-backup overwriting a lot of files for nothing and taking a long time. Let me take an example to clarify things. 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 Ouch! Second weird thing is that absolutely no diff between C and B is stored nor in the data itself, nor in the metadata Now looking at the source files : their access times (and only these ones) have been updated at the time of the backup (thus rdiff-backup does something that changes this). Looking at the destination files : their access and change times have been updated also but not the modify time. Last very weird thing : if I run a rdiff-backup --compare-at-time 1B (thus comparing current files with old B backup), it returns no changes ... !!! At now my thinking is that rdiff-backup views a difference while there isn't when running in the backing up context but clearly see that there isn't in the comparing context. I also runned a rdiff-backup --compare every 5 minutes with a cronjob and it always return no changes except at the time where the backup started. Thus it seems that riff-backup is itself fooling itself... But not sure because if I run things manually (instead of cronjob), everything works fine. I don't know why I'm having this behavior at now but for sure I'd like to prevent it to appear. ;-) Did anyone already have this behavior ? And eventually found the cause and fix that ? As information, below the characteristics of the system (and between parenthesis the ones of the other machine when everything works well as comparison). - rdiff-backup version : 1.2.8 (1.2.8) - OS : Kubuntu 11.04 (Debian Wheezy) - kernel : 2.6.38 (3.2.0) - launching way : cronjob (cronjob) - source FS : ext4 (ext3) - destination FS : ext4 (ext4) So basically only noticeable difference is a quite old kernel on the screwing up machine. I will increase verbosity of rdiff-backup and keep you updated. In between, thanks in advance for any help and support. Feel free to ask if missing information can help. Best regards, Matthieu ___ 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 ___ 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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
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: rnicholsnos...@comcast.net To: rdiff-backup-users@nongnu.org Date: 17/11/2012 23:24 Subject: Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't Sent by: rdiff-backup-users-bounces+matthieu.rioteau=skf@nongnu.org On 11/16/2012 04:21 AM, matthieu.riot...@skf.com 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 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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
On 11/19/2012 02:50 AM, matthieu.riot...@skf.com wrote:
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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
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
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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
Hi Matthieu, I had only a quick read of your mail, but for me it smells hardware problem. Have you cross-checked your cables, interfaces and storage medium? Regards, Nicolas On 2012-11-16 11:21, matthieu.riot...@skf.com wrote: Hi all, I recently decided to choose rdiff-backup as backup tool on 2 Linux machines. One is running it perfectly. But the other one has a strange behavior when running rdiff-backup. Actually, it find differences in a lot of files while there isn't any. This leads to rdiff-backup overwriting a lot of files for nothing and taking a long time. Let me take an example to clarify things. 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 Ouch! Second weird thing is that absolutely no diff between C and B is stored nor in the data itself, nor in the metadata Now looking at the source files : their access times (and only these ones) have been updated at the time of the backup (thus rdiff-backup does something that changes this). Looking at the destination files : their access and change times have been updated also but not the modify time. Last very weird thing : if I run a rdiff-backup --compare-at-time 1B (thus comparing current files with old B backup), it returns no changes ... !!! At now my thinking is that rdiff-backup views a difference while there isn't when running in the backing up context but clearly see that there isn't in the comparing context. I also runned a rdiff-backup --compare every 5 minutes with a cronjob and it always return no changes except at the time where the backup started. Thus it seems that riff-backup is itself fooling itself... But not sure because if I run things manually (instead of cronjob), everything works fine. I don't know why I'm having this behavior at now but for sure I'd like to prevent it to appear. ;-) Did anyone already have this behavior ? And eventually found the cause and fix that ? As information, below the characteristics of the system (and between parenthesis the ones of the other machine when everything works well as comparison). - rdiff-backup version : 1.2.8 (1.2.8) - OS : Kubuntu 11.04 (Debian Wheezy) - kernel : 2.6.38 (3.2.0) - launching way : cronjob (cronjob) - source FS : ext4 (ext3) - destination FS : ext4 (ext4) So basically only noticeable difference is a quite old kernel on the screwing up machine. I will increase verbosity of rdiff-backup and keep you updated. In between, thanks in advance for any help and support. Feel free to ask if missing information can help. Best regards, Matthieu ___ 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
Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't
On 11/16/2012 04:21 AM, matthieu.riot...@skf.com 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 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] Weird behavior of rdiff-backup : founding diffs while there isn't
Hi all, I recently decided to choose rdiff-backup as backup tool on 2 Linux machines. One is running it perfectly. But the other one has a strange behavior when running rdiff-backup. Actually, it find differences in a lot of files while there isn't any. This leads to rdiff-backup overwriting a lot of files for nothing and taking a long time. Let me take an example to clarify things. 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 Ouch! Second weird thing is that absolutely no diff between C and B is stored nor in the data itself, nor in the metadata Now looking at the source files : their access times (and only these ones) have been updated at the time of the backup (thus rdiff-backup does something that changes this). Looking at the destination files : their access and change times have been updated also but not the modify time. Last very weird thing : if I run a rdiff-backup --compare-at-time 1B (thus comparing current files with old B backup), it returns no changes ... !!! At now my thinking is that rdiff-backup views a difference while there isn't when running in the backing up context but clearly see that there isn't in the comparing context. I also runned a rdiff-backup --compare every 5 minutes with a cronjob and it always return no changes except at the time where the backup started. Thus it seems that riff-backup is itself fooling itself... But not sure because if I run things manually (instead of cronjob), everything works fine. I don't know why I'm having this behavior at now but for sure I'd like to prevent it to appear. ;-) Did anyone already have this behavior ? And eventually found the cause and fix that ? As information, below the characteristics of the system (and between parenthesis the ones of the other machine when everything works well as comparison). - rdiff-backup version : 1.2.8 (1.2.8) - OS : Kubuntu 11.04 (Debian Wheezy) - kernel : 2.6.38 (3.2.0) - launching way : cronjob (cronjob) - source FS : ext4 (ext3) - destination FS : ext4 (ext4) So basically only noticeable difference is a quite old kernel on the screwing up machine. I will increase verbosity of rdiff-backup and keep you updated. In between, thanks in advance for any help and support. Feel free to ask if missing information can help. Best regards, Matthieu ___ 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
